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ABSTRACT 



This thesis describes a component-based methodology for developing a new class 
of systems called spatial decision support systems (SDSS). The methodology is 
presented within the context of the development of the ARIES (Army Reserve 
Installation Evaluation System) software application, an SDSS designed to evaluate and 
compare site desirability for Army Reserve unit locations. The ARIES SDSS consists of 
a flexible component-based architecture that seamlessly integrates a user interface, GIS, 
multi-criteria decision model with associated DSS, and data warehouse. 

To build the SDSS, the ARIES developers introduced a new architectural 
paradigm, undertaking a collaborative approach with U.S. Army Reserve Command 
(US ARC) decision-makers to rapidly prototype ARIES using component-based 
technologies. The developers implemented several domain-specific architectures using a 
formalized proof-of-concept heuristic, Concept-to-Code (C2C), which conceptualizes 
user requirements in architectural terms, and migrating legacy data sources into a spatial 
data warehouse. 

C2C allowed the resultant ARIES application to be conceptualized initially in 
general terms, and then specialized architecturally around existing off the shelf 
components, as design requirements were collaboratively prototyped and implemented 
within the existing US ARC information system infrastructure. C2C facilitated the 
complete development of a complex, map-based system and accompanying data 
warehouse in the span of a few months with a technical team of three analysts and 
programmers. Significant system performance gains resulted from instituting a Migration 
Architecture System (MARS) engine to extract and spatially enable relevant data sources 
for geographic querying. Additional performance enhancements were also obtained 
through the use of rapid, component-based development techniques. 
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I. 



INTRODUCTION. 



“There is nothing more difficult to take in hand, more perilous to conduct, or 
more uncertain in its success, than to take the lead in the introduction of a new 
order of things. ” 

Niccolo Machiavelli, The Prince, 1532. 

'‘'‘We are living in an information age where almost everything is seen as 
technically possible given the commitment and the resources.'’’ 

Martyn Jones, 

“Information: It’s Architecture and Management”, 1997. 

'‘'We can no longer afford stovepiped systems. And it’s not Just an affordability 
issue, it ’s a warfighter issue. ’’ 

General Ronald Griffith, Vice Chief of Staff of the Army, 1997. 



A. THESIS OVERVIEW. 



The primary purpose of the research conducted for this thesis is to investigate and 
document the architectural approaches used in developing the Army Reserve Installation 
Evaluation System (ARIES) spatial decision support system (SDSS) for the United States 
Army Reserve Command (USARC). The objective of ARIES is to automate the process 
of evaluating, potential relocation sites for units of the Army Reserve from the vantage 
point of military readiness. 

Successful implementation of the ARIES SDSS could greatly assist the Army 
Reserve in its effort to ensure that a consistent, analytical approach to relocating units is 
adopted. Additionally it would also significantly reduce the time spent by USARC 
decision-makers manually tracking, calculating, and assessing the multiple criteria 
relevant to each facility’s site desirability. The use of information technology (IT) in the 
form of an architecturally-driven prototype application can improve the quality, 
timeliness, and accuracy of the Army Reserve Unit relocation decision specifically, and 
of similar spatially oriented decisions in general. 
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B. THE MOTIVATION FOR ARIES. 



The sponsor of this research is the Force Support Package (FSP) Readiness 
Office, a hierarchical component of USARC based in Atlanta, Georgia. This group is 
tasked with properly assessing and improving the military readiness of priority Troop 
Program Units (TPU). In the spring of 1996, several field-grade officers of the FSP 
approached the Naval Postgraduates School (NPS) building a decision support system to 
automate and expedite the selection process for relocating Army Reserve units. The 
manual process currently in use is unnecessarily complex, unwieldy, and limiting for 
USARC decision-makers, and a technical solution offers increased degrees of freedom in 
making these crucial readiness decisions. 

Under the mantra of ’’‘‘Resources to Readiness'’, USARC and NPS formed a 
collaborative partnership to explore the concept of automated decision-making for site 
location decisions. The research project was undertaken by an NPS team of two 
academic principal investigators and three application developers. This team identified 
location as one of the critical factors affecting unit readiness, and based upon this 
assumption, implemented a computer based decision model to support the unit relocation. 
A spatial decision support system was used to leverage the geographic nature of the 
decision problem. 

C. OBJECTIVES, SCOPE, AND METHODOLOGY. 

1. Objectives. 

The ARIES application was accomplished by integrating a multi-criteria Army 
Reserve unit-decision model (ARU-DM), over a dozen USARC data sources and 
geographic information system (GIS) into a SDSS. The SDSS was developed using rapid 
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prototyping based upon a component-based development heuristic, Concept-to-Code 
(C2C), and domain-specific architectures. The design heuristic was used as a structured 
means to assist the end users in conceiving the desired system, to facilitate development 
of a Data Migration Warehouse (DMW), and to enable the developers in systematically 
engineering the SDSS application to fit within the existing USARC Headquarters IT 
infrastructure. 

The objective of this research is to describe how the C2C approach facilitated the 
development of a complex, map-based, multi-criteria decision support system with a 
small team in a matter of months. 

2. Scope. 

This thesis addresses only the issues involved in architecturally developing and 
implementing the ARIES SDSS using component-based technologies. For a more 
complete examination of the issues involved in framing the Army Reserve Unit Decision 
as a Multi-Attribute Utility Theory model, refer to LCDR Mark A. Murphy’s master’s 
thesis Automated Spatial Decision Support System for the Relocation of Army 
Reserve Units'' (Murphy, 1997). Additionally, the development of the Data Migration 
Warehouse was spearheaded by LCDR Robert W. Dill and the issues of data warehousing 
and data quality are discussed in his master’s thesis '’’Data Warehousing and Data 
Quality for a Spatial Decision Support System ” (Dill, 1 997). 

3. Methodology. 

The primary function of the ARIES SDSS is computation of the twenty decision 
parameters identified in the ARU Decision Model from the extracts of designated data 
sources in accordance with elicited processes and user selections. USARC specified that 
the ARIES SDSS should access only the existing Information Systems (IS) infrastructure 
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and historical databases as the primary sources for computing decision model parameters. 
This avoided the need for additional data collection and data normalization. The impact 
of this constraint on the ideal model structure, derived from user specified requirements, 
was carefully evaluated and implemented. Managed data resources were properly 
identified from those readily available to USARC. The consolidation of multiple sources 
into an appropriate database schema for this software application presented a significant 
technical programming challenge. 

Due to the limited availability of programming resources and user specified 
requirements, the SDSS needed to integrate various commercial software tools. An 
RDBMS and a DSS were combined to manage and manipulate the data. Because of the 
spatial significance of many of the variables, a GIS was also incorporated for both 
displaying, selecting, and manipulating the information. The proposed software system 
contains five major subsystems: the ARU decision model, a single point user interface, 
data migration management, geographic information system (GIS), and a client-server 
architecture design. 

To rapidly accomplish these tasks required the development team to concurrently 
innovate and integrate several technical disciplines in ways not previously envisioned. 
The final result was a SDSS prototype that incorporates the leading-edge aspects of 
spatial mapping, geographic selection, data warehousing, and decision support 
technologies. 

Component-based application development based upon a systematic and 
architecturally-driven approach was used in developing the ARIES SDSS client-server 
architecture. Rapid prototyping techniques were also used to conceptualize the product 
design in accordance with user requirements and provide functionality for differing levels 
of detail in capturing the decision knowledge. 
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The current version of the ARIES SDSS prototype was implemented by the NFS 
development team using Microsoft’s Visual Basic for Applications (VBA) programming 
language with and third-party software including Mapinfo Corporation’s integrated 
mapping components, Mapinfos’ Basic development language, and the Logical Decision 
for Windows (LDW) decision support system. The SDSS was based on the client-server 
computing model and used the Microsoft OLE 2.0 communication protocol as the 
primary means of component communication. 

D. ORGANIZATION OF THESIS. 



This thesis contains useful information on building applications using component- 
based development from a software architectural point of view. It should be particularly 
valuable to decision-makers, information system architects, computer programmers, and 
data managers. The balance of this study is structured into several modules and 
organized as described below: 

• Chapter II - Opens with a futuristic scenario description about potential uses 
for next generation ^EXGEN) versions of ARIES. Additionally, a 
background discussion is provided about the US ARC organization, their need 
for a SDSS and an overview of the intended system. 

• Chapter III - Discusses the benefits of using component-based development 
in conjunction with a new software architectural paradigm (Architectonic) 
through the use of a design heuristic (Concept-to-Code). This chapter closes 
by describing the ARIES SDSS creation using the design heuristic. 

• Chapter IV - Discusses the lessons learned from using component-based 
development and rapid prototyping when developing complex spatial 
applications using existing infrastructure. 

• Chapter V — Provides future recommendations for further study and presents 
the conclusions of this thesis study. 
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II. BACKGROUND. 



‘‘‘‘Nothing is Built unless it is Imagined First. ” 

NRaD “Command Center of the Future” Motto. 

‘‘‘‘Our ability to imagine complex applications will always exceed our ability to 
develop them. ” Grady Booch, Object Solutions, 1996. 

‘‘‘‘The hardest single part of building a software system is deciding precisely what 
to build." Fred Brooks, “No Silver Bullet”, 1987. 

A. FUTURE SCENARIO. 

1 158 HRS : Colonel Jackson R. McMurdo, Army liaison to the newly formed 
BRAC Commission 2000 on active and reserve Army unit basing matters, was looking 
forv/ard to devouring his pastrami on rye when the phone rang unceremoniously. He 
answered impatiently and immediately recognized the frantic voice of Randolph Braid, 
Senator Jeremiad Beauregard’s BRAC aide. McMurdo knew the drill without hearing 
another word. As the BRAC chairman, the senior Senator from the Southeast was taking 
considerable heat from the Senate Armed Services Committee about closing bases V, X, 
Y, Z, and corresponding Army unit relocation. An alternative plan consisting of only 
closing bases X, Z, and adding bases W and U had been suggested by the Committee, 
wherein the displaced Army units would be relocated to base Y. This was an 
unanticipated scenario based on previous assumptions and findings, and the Senator 
would need this counter-proposal analyzed before reconvening within the hour, or the 
whole BRAC list could lose the full support and recommendation of the Armed Services 
Committee. 

“How does it look if we keep open bases V and Y and close bases U, W, X, and 
Z?” Braid asked breathlessly. 
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“Off the top of my head it appears to be a viable alternative, but I’ll have to run it 
through the SDSS to be certain.” McMurdo disliked these incessant fire drills from 
Congress and let his pique slip ever so lightly into his tone. 

“Jack, we need you to disregard the condition of the equipment and facility age, 
and focus instead on civilian employment and impact on the community at large if those 
bases are closed and their units relocated.” 

“Consider it done. Just ensure the Senator’s NetPC PointCast is set to receive 
multi-broadcast material and the multimedia presenter is in automatic mode.” 

“Understand. Thanks Jack,” said Braid contritely, hanging up his cellular phone. 

1206 HRS : Turning in his chair while setting his lunch aside. Colonel McMurdo 
stoically started his wireless laptop and logged into the Pentagon’s DoD Intranet. 
Accessing the U.S. Army website, he launched the ^^ARGIS 21” applet and began 
configuring the network user interface (NUI) for the appropriate mapping component and 
DSS model preferences. 

He then entered the Dept of the Army Data Warehouse and chose the applicable 
DataMarts and databases on military leadership, readiness, competition, and status-of- 
forces to be integrated with the 0MB Economic/Financial databases and U.S. Census 
Bureau City/State DataWarehouse. 

1209 HRS : Selecting the “Build Scenario” function, the ARGIS DataMigrator 
began extracting and conditioning the desired data to a disposable database on a remote 
RDBMS server. Simultaneously, the ARGIS Dataintegrator began creating various 
communication links to the BRAC decision model, spatial mapping components, and the 
new BRAC DataDepot. 

1217 HRS : Colonel McMurdo graphically chose the Army units and bases to be 
evaluated and executed the scenario analysis. Using remote automation workflow 
technology, the process co-opted idle network processors to achieve a standard solution 



8 



in two minutes. From this baseline the Colonel reduced the weighting on facility age and 
condition whiling increasing civilian employment valuations. He did not like what he 
saw. 

1221 HRS : Defining a 300 mile radius “what-if ’ circular analysis polygon around 
the target site, the Colonel redirected the ARGIS AI-Analyzer to determine which units 
must be moved to the target site of interest to achieve the desired outcomes. ARGIS 
reverse engineered the spatial environment and recommended several courses of action 
and budgetary schedules to achieve the objective over the course of the base closing 
timeline. This looked much better. McMurdo recognized the resultant solution as one 
minimizing the economical impact to a thriving community. He reviewed and selected 
the analysis summaries that respectively best supported and contradicted the Committee’s 
argument . 

1232 HRS : Using the ARGIS Animator, he converted the analysis to a data 
visualization movie displaying the best solution with different color-coded alternatives 
over time as bases closed and units relocated. He graphed the economic impact 
thematically per site over time and marveled at the efficiency of the system. 

1244 HRS : The telephone rang again. It was Braid once more. “Jack, the 
committee’s reconvening early! What have you got? We have to tell them something.” 

“No problem, I have just broadcast the textual analysis to Beauregard’s NetPC on 
the Senate floor and the ARGIS Solution should be playing on the large-screen display as 
we speak.” McMurdo was calm and amused as he noted the contrast of his demeanor 
with Braid’s anxiety. 

“Thanks Jack,” said Randolph. “You saved our bacon on this one.” 

1701 HRS : Jack tuned his computer into the Inet-CNN broadcast and allowed 
himself a small nod of satisfaction to see the lead story was about a remarkable 
breakthrough in the BRAG closure plan impasse. As newscast switched to the ARGIS 
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animation film, a voice-over announced in serious tones, “In a dramatic eleventh hour 
move, a compromise was reached in the Senate today.” 

As he watched the screen, his mind lamented about his previous assignment to 
USARC Headquarters so many years ago. Catching himself smiling. Jack spoke aloud, 
“Who would have thought the progeny of the ARIES project would have been so. . . . 

B. USARC AND READINESS. 

The previous scenario may seem like a work of science fiction, but given the 
continued proliferation of information-based technologies, this future may be a lot closer 
than we think. Until a year ago, if the United States Army Reserve Center (USARC) 
needed to move a reserve unit, the analysis to manually evaluate several alternatives 
required a Herculean effort on the part of the Army analysts. The proposed site selection 
process could take up to 30-40 days to develop just a partial solution. This was due to the 
complexity of the decision, multiple disparate data sources, quantifying subjective 
judgments, and analyzing approximately 1300 possible alternatives. Today, with the 
successful partnership between USARC and the Naval Postgraduate School (NPS), the 
same analysis can be completed in minutes using a deployed stand-alone Spatial Decision 
Support System (SDSS) called ARIES, that shares many similar concepts to ARGIS 21, 
only in a more primitive and prototypical form. The ARIES concept consists of a 
delivery portion and a data and applications portion. The delivery system includes COTS 
hardware and software that provides workflow automation by calculating design model 
parameters. The data and application software satisfied the functional requirements for 
maintaining the data sources, automating business processes, and interfacing with the 
decision-makers. 

The purpose of this research is to increase readiness using Information 
Technology (IT) in a manner that will dramatically improve the process used to select 
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relocation sites for Army Reserve Units. The final outcome is a repeatable and accurate 
process whose cycle time collapses from 40 days to an average of eight minutes per site 
selection scenario. 

These order-of-magnitude improvements in analysis capability can be directly 
linked to the decentralized improvement in IT practices from host-based computing 
(mainframes) to a distributed, network-centric computing environment. Computing 
environments that previously were relatively simple have exploded into a plethora of 
networks, clients, servers, and component-oriented systems. Computing complexity has 
skyrocketed and with it the future potential for greater usage. Technological choices, 
although daunting, have now begun to take into consideration the issues of scalability, 
extensibility, and an increasingly uncertain future. Technological solutions are becoming 
the means to effectively and efficiently increase military readiness. 

At the 1994 Software Technology Conference in Salt Lake City, Utah, the 
Honorable Emmett Paige, Assistant Secretary of Defense for C3I illustrated the strong 
interdependence that exists between information technology and military readiness in his 
keynote address; 

Software drives Military Readiness. As such, our military state of 
readiness is changing to support fighting and winning two major regional 
conflicts at the same time. As the world situation changes, it becomes 
increasingly the case that we will have to project our military capability 
with less notice and more precise results. The Secretary of Defense has 
made it clear that our highest priority must be readiness. We must get our 
software act together... and provide the support that our war fighters need, 
wherever they are, no matter how short a notice. And we must proceed 
with a sense of urgency in making our software become predictable, in the 
sense of its high quality and high contribution to the defense mission. 

(Paige, 1994) 

This situation presently confronts all military commands, and the work described 
in this thesis takes a useful step forward in answering the challenge of increased readiness 
for the U. S. Army Reserve Command. 
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1. United States Army Reserve Command. 



Public Law 101-510, the Defense Authorization Bill of November 5, 1990, 
provided for the establishment of a U. S. Army Reserve Command under the command of 
the Chief of Army Reserve (Figure 2-1). “Since the completed transition on September 
30, 1992, the USARC has assumed peacetime command and control of all United States 
Army Reserve forces, except for Special Operations elements and United States Army 
Reserve forces located outside of the continental United States” (DOD IG, 1993, p. 12). 

The Department of Defense’s 1993 Inspector General, described the USARC 
mission objectives as follows: 

• “Command, control, support, and ensure wartime readiness of the U.S. Army 
Reserve Forces. 

• Organize, train, and prepare U. S. Army Reserve units for mobilization and 
commitment to a wartime theater of operations. 

• Manage and execute all Operations and Maintenance, Army Reserve (OMAR) 
and Reserve Personnel, Army (RPA) funds allocated by Headquarters, 
Department of the Army. 

• Support mobilization as directed by FORSCOM.” (DOD IG, 1993, p. 14) 

In order to comply with these ascribed functions, USARC “...decision-makers 
must be able to effectively manage the resources supporting readiness and mobilization 
preparedness” (DOD IG, 1 996, p. 22). 

The capability to accomplish this goal is directly related to the 
management and availability of information. The existing. ..Army Reserve 
information systems are unable to provide timely and accurate information 
to decision-makers to.. .[enable either unit relocation or] mobilization 
planning.. .as required to meet contingency plans. (DOD IG, 1996, p. 22) 

The Army Reserve Command must often manually compile 
information requested by commanders and higher headquarters. 
Additionally updating information is time and manpower intensive and, 
therefore, is often not done as frequently as needed. (DOD IG, 1996, p. 

23) 
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Figure 2-1. U.S. Army Reserve Management Structure. 
After (DOD IG, 1993, p. 13) 
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With the 1 994 Department of Defense stipulation to buy Commercial Off-The- 
Shelf (COTS) technology whenever possible, USARC is currently migrating its 
information systems and networks from legacy applications and databases to well- 
supported commercial software suites running Microsoft Windows 95 and NT-based 
environments. 

Because of the huge expense of maintaining and operating legacy information 
systems, limited resources are available for new application development. Failure to 
think strategically about software development has lead to the formation of many stove- 
piped applications and “data silos of information.” In order to counteract this downward 
spiral, the high costs of these systems must be effectively leveraged using commercial 
technology. Instead of deploying systems that meet USARC’s short-term needs, USARC 
needs to develop applications capable of change and of evolving with changing business 
processes. 

In response to this challenge, USARC established a partnership with the Naval 
Postgraduate School to develop an Army Reserve Unit Decision Model (ARU-DM) and 
SDSS prototype to automate the site relocation analysis of existing reserve 
facilities/units. 



2. Readiness Issue. 



The sponsor of this research is the Force Support Package (FSP) 
Readiness Office, a recently formulated component of the U.S. Army 
Reserve Command. This group is tasked with assessing and improving 
the readiness of priority Troop Program Units (TPU) across the country. 

A TPU is the basic building block of the Army Reserve force, typically 
consisting of about 150 reservists. The TPU’s that are of most concern to 
the Readiness Office are in the FSP, which are the units designated for 
rapid deployment. (Murphy, 1997, p. 1) 

Military readiness can be classified into two types, operational and structural, 
which differ in granularity (Betts, 1995). Operational Readiness deals with status of 
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individual units whereas Structural Readiness deals with the overall force structure in the 
sense of “how soon a force of the size necessary to deal with the enemy can be available” 
(Betts, 1995). The focus of this research is on the operational readiness of those Army 
Reserve units scheduled for rapid deployment. In this context, readiness primarily refers 
to personnel readiness, the ability to maintain enough properly trained and qualified 
people. 

The statistics chosen by USARC decision-makers to function as the primary 
indicators of unit operational readiness are Fill Level, MOS Qualification Level, and 
Turnover Rate. The high personnel turnover rates recently suffered by the USAR have 
significantly reduced readiness. With the average retraining period lasting nine to ten 
months, between 20 and 30 percent of the required positions are routinely filled by 
unqualified, non-deployable individuals (Murphy, 1997, p.l3). Although Military 
Occupational Specialty (MOS) qualifications are not always a direct measure of 
warfighting capabilities, unqualified individuals directly diminish the number of soldiers 
available to supplement active forces. 

Performance in these areas can be related to numerous location-dependent factors, 
ranging from access to preferred recruiting markets and distances to various training 
support sites. The most significant location related factor is the recruiting market; for 
unlike the active services, reserve units must recruit exclusively from the local 
population. When a unit is struggling to maintain personal readiness, sometimes the best 
solution is unit relocation. This thesis is based on the “...premise that, holding all other 
readiness variables constant, it is possible to improve the operational readiness of some 
Army Reserve units by relocating them to preferred areas as indicated by a variety of 
location-related attributes” (Murphy, 1997, p.l3). 
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3 . 



Army Reserve Unit Decision Model (ARU-DM). 



Before the ereation of a manageable model could proceed, it was necessary to 

clearly define the TPU relocation problem. 

Although USARC representatives suggested a variety of ways in which to 
understand the importance of unit location (e.g., distances, market 
supportability areas, overlap between units, etc.), it quickly became clear 
that the primary objective was to relate location to unit readiness. The 
decision was made to develop a [decision] model that could isolate and 
evaluate the location sensitive portion of the unit readiness problem. 
(Murphy, 1997, pp. 19-20) 

“Our methodology was to interview the USARC experts to determine: 

• A goals hierarchy consisting of intermediate goals and decision parameters, 

• Tradeoff functions for each parameter in the goals hierarchy, and 

• [Identify the appropriate] weights for each of the parameters.” (Dolk, et. al., 
1996). 

Based upon the concerns and priorities of the USARC experts, the NFS 
development team decomposed the overall objective of Site Desirability into twenty 
measurable decision parameters. These parameters were identified as objective, 
measurable attributes of a desired site location and loosely grouped together in three 
categories: People, Places, and Things (Table 1). 



pEoPOT 



FLACBS 






Competition 
Area Drill Attendance 
Area Loss Rate 
Area Transfer Rate 
Average Area Manning 
Closing Unit Transfers 
IRR Available 
Recruit Market 
Reassignments 



Facility Age 
Facility Backlogged Maintenance 
Facility Condition (RED / AMBER / GREEN) 
Facility Operating Costs 
Facility Government Owned (Y/N) 
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Facility Weekend Usage 


THINGS 


Distance to Recruiter 
Distance to AMSA 
Distance to ECS 
Available MOS Closing 
Available MOS IRR 



Table I. Army Reserve Unit Decision Model (ARU-DM). 
a. General Assumptions 



Although this modeling effort “...does not provide a rigorous, causal 
model of readiness, it is assumed that the hierarchy of screening factors provides a 
meaningful assessment of the propensity of a given location to support the achievement 
of high levels of readiness” (Murphy, 1997, p.31). For the ARU decision model, the 
expert panel assumed that the basis for evaluation would be a single reserve unit. One 
alternative to this, relocating a portion or derivative of a unit, may sometimes be more 
appropriate, but this was not considered in the decision model. Secondly, derived reserve 
unit metrics had to be calculated directly from data sources available on the USARC local 
area network which would be implemented in the final application. Lastly, the “area of 
the proposed site” refers to the region within 50 miles of the zip code centroid center in 
which the proposed site is located. 

This proposed location will have little or no influence on where people 
chose to live. People will not move just to be closer to the unit or relocate 
when the unit does. (Murphy, 1997, p. 30) 

b. Goals Hierarchy 

Using the identified decision parameters, the ARU relocation decision was 
structured into a goals hierarchy using Multi-Attribute Utility Theory (Figure 2-2). 
Location data are extracted and conditioned from USARC’s corporate data sources and 
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hierarchy is organized by its type (goal, subgoal, or parameter) and identified by the 
hierarchical level at which it exists. Within each section, components are listed 
alphabetically and levels are ordered from top to bottom. After (Murphy, 1997) 
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converted to common units of reference using twenty different utility function curves. 
There was one utility curve developed for each decision parameter. The outputs of these 
utility functions are repeatedly combined, based on the hierarchical structure of the ARU- 
DM and the relative weights elicited from the experts, to produce the overall scores used 
to rank the alternative sites. 

c. DSS Software Component 

The COTS software package selected by the NFS Development Team for 
implementing the ARU-DM was Logical Decisions for Windows (LDW). It was chosen 
as the DSS software component “...primarily because it supports explicit specification of 
tradeoff functions for each parameter as well as five different decision analysis 
techniques, both quantitative and qualitative” (Dolk, et. al., 1996). 

4. USARC Source Data. 

The SDSS prototype was originally implemented as a stand-alone Windows 95 
version but is currently operating in a Windows NT environment on the USARC 
Headquarters’ Local Area Network (LAN). One of the stipulated pretexts of the 
prototype was that the databases currently present on the USARC LAN are the only data 
sources eligible for deriving ARU-DM parameters. The primary reason for this is that 
USARC wanted to be able to deploy the SDSS application without having to shift the 
burden of administratively supporting it to the USARC IS Staff. 

The native data sources are composed of a multitude of large multi-vendor 
databases (Table II). These databases are mostly flat file structures that were haphazardly 
instituted to support several independent USARC applications as they were deployed on 
the LAN. Some of the files are ad hoc derivatives of larger off-site mainframe-based 
databases, periodically updated from USAR Headquarters in Washington, D.C. 
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Ownership and maintenance of the local data sources is distributed amongst the primary 
user base of the stove-piped applications (Appendix A). Additionally, there is no 
centralized data dictionary or repository maintained for the data sources or the metadata 
that constructs them. Consequently, there is little consistency between the data source’s 
design, structure, format, or key index fields. Database field names are different for 
similar data sets, and most of the files contain incomplete, inaccurate, and missing data. 
This complete lack of common institutional data standards greatly complicated the 
development of an integrated data framework for the SDSS prototype (Figure 2-3). To 
compensate for this unexpected lack of data quality and to provide a stable baseline 
database for deriving the decision parameters, the development team was compelled to 
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Table II. Source Data Tables. 



concurrently design and implement a Migration Architecture System (MARS) engine, 
and a data migration warehouse (DMW) variant — DataDepot (Figure 2-4). 
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Figure 2 - 3 . SDSS Disparate Data Sources Flow Diagram 
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Figure 2-4. SDSS Migrated Information Flow Diagram 
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5. Information Systems Challenge. 



Because the entire TPU relocation decision incorporates such a large number of 
parameters, it is nearly impossible for an unaided human decision-maker to fully consider 
all relevant factors. In the past these decisions were typically based upon a combination 
of intuition and experience, but this ad hoc process was often difficult to build a 
consensus for, communicate, and defend. 

Frustrated with the inadequacies of the approach to such a complicated problem, 
the large number of characteristics per facility, the number of analyses required, and over 
1300 facilities to evaluate, the Army Reserve believed it could deliver 
morecomprehensive relocation decisions by applying a Geographic Information System 
(GIS) and decision-support technology to the relocation decision process. In addition the 
decision support technology had to allow the USARC decision-maker to perform a 
variety of ad hoc analyses of multiple readiness factors to ensure that the relocation 
recommendation was truly warranted and was in the best interest of the moving unit. 
This was the inspiration for a fully automated software application that could select, 
calculate, and deliver spatially-oriented decision data to the ARU Decision Model. This 
visionary aspect of the NFS Initiative, “A Geographic Information System Approach to 
USAR Unit Readiness,” inspired the development of just such an application — the 
Army Reserve Installation Evaluation System (ARIES). 

In order to minimize application development time and maximize previous 
USARC computing investments, it was important that the automated ARIES system 
utilize the USARC IS infrastructure, COTS applications, and historical databases as the 
primary components for computing the decision model factors (Figure 2-5). 
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Figure 2-5. ARIES Conceptual Infrastructure Diagram. 



Additionally, the NFS development team also wanted to prevent the construction 
and deployment of yet another requirements-driven stove-piped application (Figure 2-6), 
instead building one that was architecturally-driven (Figure 2-7). By this I mean an 
application in which the specific requirements are traceable, the architecture is not 
resistant to change, and the coding is kept to minimum by leveraging the existing 
software infrastructure. This is the real challenge of developing the USARC SDSS 
application. 

To accomplish this requires a fundamental shift in the way developers think about 
and design integrated software applications. Instead of focusing on the problem as “a 
simple matter of programming,” the development team would focus on the problem as a 
complex systemic concept with interdependent resources and corresponding rule-based 
processes. To manage this approach effectively requires a new rational design process — 
the process is partially proof-of-concept exploitable, fully component-oriented, and 
architecturally refmable. 
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Figure 2-6. The Structure of Requirements-Driven Projects. 
After (Booch, 1996, p. 15) 



In the next chapter we will investigate the reasons for focusing our development 
efforts on architectural design and implementation, develop a component-based heuristic 
that incorporates architecturally-driven concepts, and specifically discuss the application 
development and implementation issues that went into designing and building the ARIES 
SDSS prototype. 
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Figure 2-7. An Architecture-Driven System. 
After (Booch, 1 996, p. 52) 
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III. ARIES APPLICATION DEVELOPMENT. 



“He who does not lay his foundations beforehand may by great abilities do so 
afterwards, although with great trouble to the architect and danger to the 
building." Niccolo Machiavelli, The Prince, 1532. 

‘Wew information technologies gradually give birth to new activities, processes, 
and products.'" John Naisbitt, Mega/reotfe, 1982. 

‘‘^By 1999, component software will be the dominant method of new application 
development (0. 7 probability)" Roy Schulte, Gartner Group. 



A. INTRODUCTION. 

There is no single product, book, management style, or “silver bullet” that 
magically leads the developer or development team through a painless application 
development process. “But a sensible use of productive complementary tools and 
techniques, and a shift to a paradigm with proven advantages can over time yield the 
desired results” (Tkach, 1996, p. xiii). In the absence of any singular solution, the ARIES 
project used a “proof-of-concept” heuristic, Concept-to-Code (C2C), to guide the 
development team. C2C provided the structural perspective needed to manage USARC’s 
requirements and the implementation of the decision model into a cohesive, integrated 
prototype using various COTS products, a fourth-generation language, and existing 
infrastructure. 

This chapter begins with an overview of component-based development and the 
new computing paradigm shift it ushers forth. Next is a discussion of the generic 
requirements of each of the C2C phases, stages, and artifacts, and the corresponding 
ARIES implementation. The final major section is a summary of the ARIES 
implementation using the C2C heuristic process. 
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B. BACKGROUND. 



1. Software Development: A Brief History Lesson. 



Prior to the 1990’s, software development consisted primarily of programmers 

and developers using conventional software development models (waterfall, incremental, 

spiral) to build applications with procedural techniques. The majority of these 

approaches involved the systematic use of five basic steps: analysis, design, 

implementation, testing, and maintenance. This was usually sufficient as long as the 

users’ requirements were clearly defined, system architectures were understood, 

complexity was low, and product delivery cycle was measured in years. 

One problem with the conventional ‘waterfall’ software development 
process is that in some situations it may not be possible to define the 
software requirements fully at the beginning of the software development 
effort. Another problem is that there may be a significant risk that the 
design approach created to satisfy the requirements may be inadequate. A 
final problem is that the user only receives the software at the end of the 
complete and lengthy process; the user may need this capability at an 
earlier time. (USAF-STSC, 1992, p. 15). 

Conventional software practices exploited “...the idea that if developers can get perfect 
specifications up front, the end result will be a perfect application” (Whitten et. al., 1994). 
Today this not the case. As computing power and user capabilities have increased with 

technological change, the following phenomena transpired: 

• The application development process has become more complex today than a 
decade ago (Tkach, 1996, p. 17). 

• “Line-at-a-time programming is. ..increasingly being replaced by point-and- 
click visual development environments” (Sama and Febish, 1996, p. 27). 

• “Interactive GUI, distributed... processing, very large integrated.. .databases 
[and] heterogeneous environments....” have become the norm. (Tkach, 1996, 
p. 17). 
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Additionally, most users have become accustomed to a window-oriented user 
interface (U/I), and subsequent interface expectations have risen accordingly. The 
application development process “...has evolved to the point that it’s becoming entirely 
GUI-based and built up from components using techniques of rapid application 
development” (Sarna and Febish, 1996, p. 27). Complex GUIs are becoming standard 
requirements that are not easily accomplished with current techniques. The software 
development methods of the past are insufficient to develop rapidly the scalable, 
extensible, and flexible applications demanded by organizations today. Speed of delivery 
and completeness of stated requirements are the mantra driving the “solution du jour.” 

Currently, organizations want software development to take into account the 
hundreds of millions of dollars invested in building IT infrastructure, computing capacity, 
and the resultant morass of accumulated data. The “waterfall” models have failed to 
provide the “silver bullet” solution to application development in today’s “Buy-It versus 
Build-It” mentality. In turn, they have become the legacy methodologies of the same 
legacy data, applications, and systems they helped to create. A better solution needs to be 
found. One answer lies in the increasing popularity of component-oriented computing; 
with the continued maturation of the software industry, component-based development is 
now seen “as an important step toward the industrialization of software that can help to 
transform programming from an arcane craft to a systematic. ..process” (Taylor, 1991, p. 
iii). 

2. Component-Based Revolution 

Component-based development, the ability to design and build from definable 
objects without the benefits of inheritance or polymorphism, is ready to be the next great 
advance in software development. Although the concept of constructing applications 
with reusable code as been available since the object-oriented revolution, it is only just 
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recently that critical mass has occurred in the computing industry. The pieces are in place 
for component-based application development to achieve mainstream status amongst 
today’s IT organizations. (Chappell, 1997, p. 1) 

The major reasons for this are: 

• The growing use and acceptance of Microsoft’s Component Object Model 
(COM) as the dominant standard for PC-based component computing. 

• Components are moving off the desktop and beginning to play an important 
role in the creation of client/server applications. 

• Broad support for designing and developing components and component- 
based applications with third-party tools and languages. (Chappell, 1997, p. 

3) 



As a developmental process, component-based development (CBD) 

“...will supplant earlier programming • archetypes, such as structured 
programming and object-oriented programming, as the approach most 
likely to yield significant productivity and reusability benefits. Its 
emphasis on iteration sounds the death Imell for the traditional ‘waterfall’ 
model of the entire development process. One of the reasons that CBD 
will gain broad acceptance is that it offers ways to address the complete 
range of software challenges, from operating system services to 
client/server development.” (Spitzer, 1997). 

Component-based development is not without its own baggage, however. As 
more and more organizations and vendors shift their focus to take advantage of this new 
wave in computing, the more susceptible they will become to the unintended 
consequences of the “revolution.” One of the biggest challenges in the component- 
oriented “revolution” so far is the utter lack of any kind of established methodology for 
effectively guiding the conceptualization, analysis, and implementation of a user-centric 
application, or managing component-based construction from infrastructure components. 

Additionally, there is not a widely accepted standards-based component 
architecture from which to develop applications. Compounding this problem is the fact 
that almost every component-oriented solution is unique in its configuration and 
implementation. Traditional software development methods do not apply. The model 
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currently most applicable is the one an organization develops for its own IS operations 
and IT environment (Hamilton, 1994, p. 43). 

The other reality is that open component architectures — with their 
interdependent servers, databases, clients, and protocols — have a multitude of potential 
connection point failures” (Hamilton, 1994, p, 43). Although, we are still better served 
by past software development practices, it continues to remain horribly expensive to 
construct custom software for automating a particular organization’s unique business 
processes (Udell, 1994, p. 47). “...Today’s major problems with software [development] 
are not technical problems, but management problems” (DOD-USD, 1987). Developers 
need an efficient means in which to manage and “pre-engineer” modular applications, 
databases, and information flows prior to deployment in a real world environment. 
Because the systematic construction of complex software applications from existing 
components remains an ever elusive goal (Garlan et. ah, 1995, p. 17). 

From a technical perspective, a combination of component-based development 
and the latest advancements in software architecture such the ARIES SDSS is required. 

The prerequisites for this would need to include: 

• A widely accepted component-oriented infrastructure. 

• Standard Domain-Specific Software Architectures (DSSA) to guide 
development and enable rapid assembly. 

• Commercial and technical environments that fully support CBD integration. 

This alone may be the most important paradigm shift in software development in 
decades. The dawn of the “industrial revolution of software,” whereby software products 
are manufactured in accordance with a specified structure and process, is upon us. 
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3. 



Architectonic Paradigm: The Shift to Structure 



“Today the term [paradigm] is widely used to define a broad model, a framework, 
a way of thinking, or a scheme for understanding reality” (Tapscott, 1993, p. xii). The 
Architectonic Paradigm — of or pertaining to principles of architecture — mandates a 
shift in conventional thinking about how developers build applications. It requires an 
architectural approach that spans both the business and technical arenas, and that adopts 
the perspective of software construction not as a craft but as a discipline (Davis, 1995). 

This new paradigm consists appropriately of the following aspects; 

• Simplicity - easy to comprehend and communicate. 

• Task-centric - must map naturally to the customers’ world. 

• Changeable - enable rapid, flexible, and scaleable paths. 

• Manageable - support heterogeneous platforms, applications and architectures. 

• Leverageable - migrate legacy systems and support COTS integration. 

In short, the Architectonic Paradigm is one in which the overall focus shifts from 
requirements-driven to architectural-driven development. It “has all the benefits of 
requirements-driven style, as well as the favorable characteristic of encouraging the 
creation of resilient frameworks that can withstand shifting requirements and 
technological calamity” (Booch, 1996, p. 21). But the days of designing an information 
system in a vacuum are over. The problems of today are up to 50 times larger in 
complexity than the problems of yesteryear, and the difficulty of developing “good 
enough” solutions is growing at an exponential rate. The developer is always trying to fit 
a new piece into a puzzle that has already been framed and to deal with quirky methods of 
interfacing with the database(s). A developer can no longer afford to build software 
applications from scratch without duly considering the existing infrastructure and several 
components — which are themselves architectures (information, application, and 



32 



technical) — contained within the structure. The Infrastructure investment holds a 
central position in any planned and future application development (Figure 3-1). 



IQsystem functions 
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COMMON INFRASTRUCTURE 

Figure 3-1. An Architecture-Driven System. After (Booch, 1996, p. 52). 

4. Infrastructure: The Invisible Hand of Structure 

The previous chapter briefly introduced the notion of architecture-driven 
programming and illustrated how it relates to infrastructure. The central idea is to 
encourage the minimal programming of new applications by using software architectures 
amd COTS products already present within the desired operating environment. An 
example in a Windows-based environment would be to develop an application’s U/I 
using Window’s API routines rather than creating new objects and classes in the C++ 
language. Additionally the use of validated infrastructure components require that new 
applications only need to be tested at the points of interaction between existing 
components and thoroughly tested for any custom designed components. This allows the 
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developer to safely assemble and application as opposed to building it. The guiding 
principle is the Basics, Custom Build only what provides Value" (Knowles, 1997). 

Many mature organizations, already dependent on information systems, are 
struggling to implement this “Best-in-Breed” approach while still maintaining their 
existing lines of business applications. To accomplish this, organizations must 
effectively forge a vision for an enterprise architectural foundation with a (capital “A”) 
and develop domain-specific frameworks that support the integration of single application 
architectures (with a lower-case “a”). Perhaps, the best approach is to fundamentally 
leverage the existing infrastructure in a manner that permits organizations and developers 
to meinage heterogeneous components, business rules, and legacy data from an 
architectural perspective. 

The ARIES development team devised the Baseline Infrastructure Archetype 
(BIA) Model to accomplish this objective, and to better understand and analyze the 
infrastructure. Although the BIA Model is generic, it forms the centerpiece of the 
Architectonic Paradigm, and offers guidance for evaluating the features of available 
components and tools used to solve problems relevant to the unique circumstances of 
individual applications. Essentially all of the pertinent technology fits into the multi- 
layer triangular model (Figure 3-2) that incorporates all three infrastructure 
subarchitectures: information, application, technical. These subarchitectures provide a 

triad of interaction for all systems within the Architectonic Paradigm; 

• Information Architecture - describes the content, behavior, and interaction of 
all the business and information requests from applications and technical 
components. The information architecture provides the database objects and 
services for application development and provides a information framework 
for other requesting resources. 

• Application Architecture - defines the fundamental services and business 
rules within the applications domain. This architecture transparently and 
seamless supports the logic and data processing of the user interface service 
requests. The components of the information architecture are modeled. 
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designed, and implemented in terms of the business rules and processes 
developed in the application architecture. 

• Technical Architecture - specifies the actual technologies (components) and 
the software tools that supply the requested services to and from the 
application and information architectures. It is used to implement the 
applications. (Aronica and Rimel, 1996) 
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Figure 3-2. Baseline Infrastmcture Archetype (BIA) Model. 



The logical layers of the BIA Model that function from the epicenter (interface layer) 
outward are: 

• Interface Layer - Provides client-side services to the resources and user. For 
a particular user the layer enables access and interaction with application 
resources. 

• Communications Layer -Functions as middleware to connect and manage the 
interface clients with various requested resources. 
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• Resources Layer - Consists of the DBMS, databases, and data; the 
applications, parts of applications and components; technologies and tools that 
implement the applications. (Hurwitz, 1997) 

Resource interactions that do not require client involvement occur at the angular 
margins, and the byproducts of interaction are conceptually maintained within the circular 
segments of the “sphere of influence”. More simply, the sphere represents the scalable 
world in which the information system functions. Whether it is a standalone desktop 
computer or a mainframe system, the baseline structure is physically different but 
logically similar. The ecological environment in which the spherical microworlds operate 

provide the common platform services; 

• Base Operating System (e.g., Windows NT). 

• Networking Communications (e.g., NetBUI, TCP/IP, etc.). 

The layers in this model are not the same as those found in a typical three- 
tier client/server model. There is no single service with a single piece of 
middleware, no single graphical user interface, and no single type of data 
all tightly connected. You should think of each layer as a category -- an 
organizing principle. (Hurwitz, 1 997). 

This layer approach allows developers to plan the function of various pieces of the 
architecture and determine what to work on first. A specific example of this model will 
be provided later in the next section. 

The next logical question is “How can the benefits of architecture be effectively 
extended to component-based computing?” The ARIES development team’s response 
was to devise and institute a methodological heuristic, Concept-to-Code, that embraced 
the Architectonic Paradigm and provided a structural perspective and the means to 
formulate a cohesively integrated application. This will be the focus of our discussion in 
the next section. 
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C. CONCEPT-TO-CODE HEURISTIC 



1. Overview 

The main disadvantage of major information system development, aside from 
architectural and infrastructural issues, is that it takes too long to implement full 
production products from untested concepts. It is very difficult to get beyond theoretical 
constructs to practical implementations. 

What is needed is a new kind of application development, one supported by a set 
of design ideas that can accommodate pre-existing applications, software infrastructure, 
and COTS products, and one employing a systematic approach independent of tool, style, 
or technique that acts to guide and direct the collaborative efforts of the users and 
developers, and that incorporates Grady Booch’s five elements of a successful project 
application: 

• Focus ruthlessly on the development of a system that provides a well- 
understood collection of essential minimal characteristics. 

• The existence of a culture that is centered on results, encourages 
communication, and is not afraid to fail. 

• The effective use of object-oriented analysis and design. 

• The existence of a strong architectural vision and principles. 

• The application of a well-managed incremental and iterative development life 
cycle. (Booch, 1996, p. 25) 

Concept-to-Code (C2C) is just that: a way of getting from a concept envisioned 
by a organization to the specific computer code needed to achieve it. C2C’s primary 
cognitive focus is to prevent the production of ill-defined software early in the 
conceptualization process. The heuristic achieves this by exploring and implementing 
practical solutions in a manner that is independent of a particular computing language. 
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DBMS, and operating environment. Simply stated, by using rapid application 
prototyping techniques and the participatory involvement of the intended users, an 
organization can get exactly what it needs in less time than by conventional methods. 

“In business system development, satisfying the needs of the users is particularly 
challenging because even the user cannot know what he wants and needs until he sees the 
system in action” (Scharer, 1986, p. 59). Because written specifications are not a good 
way to communicate with the user, rapid application prototyping was selected by the 
ARIES development team as a practical approach for developing the U/I and the 
application. Prototyping in this case becomes a method of system construction as well as 
a technique for system definition (Scharer, 1986, p. 60). Additionally, it is critical to 

remember the following when using rapid application development (RAD): 

• RAD only works when you understand the business problem. 

• RAD should not be tool-driven or tool-dependent. 

• RAD is only effective when it’s part of a sound application development 
process. (Linthicum, 1997) 

Achieving this RAD effort requires close communication and collaboration between 

intended users and a small, highly skilled development team (e.g., three to eight people). 

The task is to develop a technical artifact for a client or user with more or 
less clear and stable requirements. To cope effectively with the 
uncertainty of this task, an experimental approach is taken in which 
various models, prototypes, and versions are tried to reach a satisfactory 
solution. (Dahlbom, 1 997, p. 84) 

By using a methodology or process that integrates the combination of controlled 
development and rapid prototyping, a developer can ensure minimal risk and maximum 
benefit in design. 

In order to effectively organize the RAD process, C2C was visually conceived as 
a three-layered closed-loop pyramid structure flowing progressively from top to bottom 
and iteratively throughout the structure (Figure 3-3). Each layer represents a distinct 
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“phase change” of the collaborative process, or the completion of an iterative milestone 
of the developing application. Each phase is further sectionalized into two smaller parts 
called “stages.” As indicated, each stage flows into each other and acts to facilitate the 
focus of the user and developer. The resultant IN/OUT processes of each stage are 
byproducts of this interaction. 




The Conceptualization Phase is focused on identifying and clarifying the concept 
or problem to the extent that the prospective users are able to articulate and the 
developers are able to assimilate. The artifacts of the conceptualization phase are utilized 
by the Visualization Phase to more thoroughly analyze the problem domain, define and 
design stable component architectures, and address the riskier elements of the project. 
This phase will more than likely require several iterative feedback loops to properly 
create the U/I prototype and application architecture in accordance with the user’s 
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requirements. The Implementation Phase uses the approved byproducts of the 
Visualization Phase employing appropriate application development principles and fourth 
generation language coding skills of the developers. 

Prior to the transition from each phase/stage, a formal review and informal 
walkthrough should be conducted to ensure the resultant artifacts are satisfactory and 
design decisions sound. Usually peer-to-peer walkthroughs prevent a perpetuation of 
inconsistency and incompatibility between user requirements and developer objectives. 
“Formal reviews are intended for acquisition management users and interested parties to 
conclude a software development phase by approving the products and other results of 
that phase” (USAF-STSC, 1992, p. 55). 

A completed cycle of the C2C pyramid and acceptance of the application by the 
user represents a final incremental version that is ready to be deployed in the desired 
operating environment. “The process is incremental in the sense that each pass through 
the...[C2C] cycle leads a project to gradually refine its strategic and tactical decisions, 
ultimately converging upon a solution that meets the end user’s real (and usually 
unstated) requirements, and yet is simple, reliable, and adaptable” (Booch, 1996, p. 29). 
Later in this chapter, I will specifically address each phase and stage in turn, but for now 
it is easier to view each phase and stage as a transition point. 

The apex of the pyramid is the highest point of general abstraction and becomes 
more specialized as the developer gravitates to the foundation. Only as the user- 
developer collaborative ensemble descends the structure do specific commitments to 
particular languages, standards, and operating environments emerge, all the while 
providing a mechanism for feedback that enables architectural refinement and iterative 
development of the concept. The bisection of the upper half (user-driven) and lower half 
(developer-driven) of the pyramid, indicates the primary focus of the collaborative effort. 
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The shaded boxed regions in the first two phases illustrate where rapid prototyping occurs 
dependent on user requirements: 

The Analysis Prototype is an aid for exploring the problem domain. It is 
meant to capture users’ input and show proof-of-concept. The analysis 
prototype is not meant to be used as a basis for development and it should 
be discarded when it has served its purpose. The final product should use 
the concepts exposed by the prototype, not its code. 

The Domain Prototype is an aid for the incremental implementation of the 
solution. It can be used as a tool for staged delivery of subsystems to 
users and other developers. It demonstrates the feasibility and viability of 
the implementation and will eventually evolve into a deliverable product. 

(Tkach, 1996, pp. 52-53) 

Therefore the amount of prototyping is directly proportional to the degree the user 
is able to effectively articulate what s/he wants, needs, and desires (Figure 3-4). This 
dependency upon the judgmental influence of the user diminishes from phase to phase 
(Figure 3-5). Because of this dependency the prototyping for the ARIES SDSS will be 
discussed separately at the end of each phase narrative — each prototype situation is 
uniquely different from the previous, and at a minimum, the U/I-centric nature of today’s 
applications, increasingly demands prototyping to achieve the best fit, form and 
functionality in a very short time. 

This coordinated prototyping capability is what makes C2C far different from 
typical application development. It lends itself easily to rapid application development 
yet is iterative at each phase. “Without a [process] for managing change, all but the 
smallest, simplest projects are at risk of wandering out of control and adding time to the 
development schedule” (Forte, 1997, p. 121). The heuristic on the whole is not a cookie- 
cutter technique, but takes a “systems view” of the concept to be tested and develops the 
application in steps from concept to system to subsystem. 
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Figure 3-4. Level of Prototyping Required Graph. 




Figure 3-5. User Influence on Application Development. 



With this in mind, a more complete definition of C2C is the following: 



C2C is a formalized iterative construct, a heuristic, for developing 
“proof-of -concept” applications in a top-down, component-oriented 
architecture in which users’ objectives, business rules, and 
organizational data are defined and related to one another at the 
conceptual, technical, and implementation levels. 
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The tenet principles upon which this heuristic was based are as follows; 

• Manage the complexity of small to medium sized applications (< 100,000 
LOC) through the use of component-based techniques while still embracing 
legacy systems. 

• Focus development and modeling efforts on components whose function is 
determined heavily by the user interface and interactions with relational 
databases. 

• Where applicable, adapt to changing requirements by maintaining a strict 
adherence to open IT standards-based architectures to ensure interoperability, 
portability, scalability, and data exchange (Libicki, 1994, p.3). 

• Ensure application efforts are user-driven, not technology-driven, by 
leveraging the user and developers intellectual capital through rapid 
application prototyping. 

• Conduct integrated and continuous testing with the C2C process while 
maintaining a “high level of stability throughout the project by constantly 
evaluating the architecture, interfaces, and. ..by preventing the accumulation of 
latent defects” (Forte, 1997, p. 122). 

Now that the basics and underlying principles of C2C have been explained, we 
can delve into the specific regions of the heuristic and how they help to direct the 
development of the ARIES application. 

2. Conceptualization Phase 



Concept-based exploration begins with a broad concept — a “term... meant to 
suggest a framework that is found useful in organizing ideas and suggesting actions” — 
and proceeds into a characterization plan to determine and understand the processes of the 
organization, and identify the top level requirements and feasibility of the concept (Scott- 
Morton, 1984). It is essential to understand the business-centric aspects of the 
organization prior to developing the concept. The main goal in the first step of this phase 
is to identify the concept to be proven, and characterize it in terms with which the user is 
familiar in preparation for later software development. 
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The second step in the conceptualization process is identifying the specific 
capabilities required to execute the concept by focusing on defining as much as possible 
the elements that best characterize the organization’s stated concept. The goal is to 
develop a characterization of what the application will accomplish without getting into 
the details of how the system actually functions. The term characterization is used 
because process analysis and data gathering are not exhaustive. It is not necessary to 
document every detail. Only enough detail is required to allow informed decisions to be 
made in the creation of the component architectures and U/I prototype. Without the 
insight that a baseline characterization provides, there is a risk of devising a system 
architecture that is difficult to improve. If the customer already possesses much of the 
baseline data, more time can be spent on characterizing the environment. Iterative 
development will subsequently refine the characterization to a specific system. 

Much of this information is gathered tlirough a process of interviews with all the 
individuals (Management, IT staff, and end users) with a vested interest in the 
application; as well as a thorough audit of the existing environment. It is important that 
the intended users of the system be fully involved and participative in the conceptual 
design process. Conceptual errors made in the design are laboriously difficult to correct 
once coding has begun. Developers prefer to carefully analyze and evaluate the 
conceptual design before proceeding to the Visualization Phase. If the user has difficulty 
articulating or characterizing the concept, it is the responsibility of the development team 
to utilize prototyping as a means to elicit the desired information. The Analysis 
Prototype can help to “minimize development risks due to incomplete requirements, and 
to assess whether a user interface can be developed that will allow the designated system 
to operate effectively” (Dolan, 1994). 

Some of the basic concept characterization elements to consider are (not 
inclusive): 
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• Top-Level Requirements. 

• Scope. 

• Timeline for Product Delivery. 

• Performance Criteria. 

• Technology Base and Infrastructure. 

• Business Rules, Processes and Logic. 

The user is not asked to freeze the functional specifications during this because 
specifications can be revised or changed even after the analysis prototype refinement is in 
progress. Accordingly, this will require a different mind-set than previously conducted 
by software development teams in the past. 

a. ARIES Concept Stage 

The concept USARC was interested in investigating was whether or not 
the manual process of relocating Army Reserve units could be automated using existing 
data sources and computing infrastructure. Specifically, could a Geographic Information 
System (GIS) be integrated with an ARU-Decision Model to provide users with the 
ability to graphically select and compare reserve units through a common user interface. 
The resultant solution, a Spatial Decision Support System (SDSS), would be a new 
capability that allows the decision-maker to “pull” only the spatially pertinent data about 
desired facilities and “push” the results into the DSS model. 

b. ARIES Characterization Stage 

The desired ARIES system could best be characterized as a software 
application that spatially selects, derives, calculates, and imports the user-identified 
decision parameters into the ARU-DM using USARC data sources. 
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(1) Top Level Requirements 

• SDSS application must be a standalone “proof-of-concept” prototype that will 
execute on a USARC-furnished laptop computer running the Microsoft 
Windows 95 operating system. 

• Allow the decision-maker to manage the selection of the legacy data sources 
on the USARC LAN. 

• Implement a single, consistent user interface that allows the decision-maker to 
graphically or manually select the facilities to be compared. 

• Automate the calculation of ARU-DM parameters, using USARC business 
rules, pre-determined data processes, and a GIS. 

• Enable the batch printing of pre-determined reports from a default preference 
set. 

• Allow the decision-maker to change parameter weightings and conduct “what- 
if ’ analysis on the completed scenario. 

• Use as many USARC infrastructure components as possible without adding 
additional administrative burden to the IT staff. 

(2) ARIES Scope 

• Data Sources - U.S. Army Reserve Databases (National); Approximately one 
gigabyte. The functionality of the SDSS had to be proven with USARCs’ 
existing systems, using data the decision-makers were familiar with. 

• Inputs - Unit Identification Code (UIC) of the moving unit and up to four 
Facility Identification (FacID) unit alternatives. 

• Complexity - Support no more than 10 USARC users at a time in the LAN 
environment. 

• Constraints - For calculating applicable decision parameters, spatially select 
the closest AMSA, equipment and recruiting sites; Conduct all spatial 
selections within a 50 mile radius of the proposed site; Use USARC’s 
command plan as a master list to validate UIC’s and G17 files as the master 
list to validate FaclD’s; Indicate inaccurate or missing data for decision 
parameters with code (-999). 

(3) Timeline 

• Develop standalone prototype in approximately six months. 
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(4) ARIES Performance Criteria 



• Conduct each evaluation scenario (up to four alternatives) within two hours 
maximum; Verify each user input using master validation lists; Batch 
automate as much as possible in order to minimize user interaction and 
training. 



(5) USARC Technology Base and Infrastructure 

• Hardware (standalone) - Dell Latitude laptop computers with 90 MHz 
Pentium processors. 

• Hardware (network) - Numerous multi-vendor desktop computers with 
Pentium Processors. 

• Operating Systems - USARC LAN running Microsoft Windows for 
Workgroups 3.1 with a plan to upgrade to Microsoft Windows NT 4.0 in 
Fiscal Year 1997. USARC laptops utilize Windows 95. 

• COTS - Mapinfo Professional and MapBasic 4.0 mapping software package. 
Microsoft Office 95 Suite. 

• 4GL - Microsoft Visual Basic 4.0 Professional Edition. 

(6) ARIES Business Rules and Processes — Appendix B 



c. ARIES Analysis Prototype 

Because users cannot always articulate what their business requirements 
are or their preferences for the user interface, two forms of analysis prototyping were 
used to better conceptualize the ARIES system. 

(1) Contextual. Because direct interaction between USARC 
and NPS was restricted to a maximum of two days per month a contextual style (story- 
boarding) of prototyping was used to elicit from the users the desired functionality of the 
common user interface in terms of visual appearance, menu choices, program controls 
and toolbar capability. The idea was to distill the “signal from the noise” by starting from 
the user’s perspective and rapidly discussing, diagramming, and receiving feedback about 
various interface ideas and alternatives. As each iterative cycle was completed, the 
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interface became more refined, until all sides agreed upon a interim design. The final 
computer-based design was completed later as a byproduct of the component architecture 
prototype in the Visualization Phase. 

Because the application was to execute in a Microsoft Windows- 
based environment, it was important to the users that the user interface mimic and 
leverage Windows-based functions as much as possible. The main objective was an 
application that required a minimum amount of training for experienced Windows users 
and fulfilled all of the stated requirements. To achieve this, the collaborative team agreed 
that all program views and controls would be subordinate to, and represent only one item 
at a time within the confines of a master window view. This was needed to maximize 
user comprehension and minimize confusion. The particular views and controls are as 
follows; 

• Provide a Map View that enables the user to graphically select desired units 
and monitor the progress of facility comparisons that are spatially selected and 
calculated. 

• Provide a Selection Panel that enables the user to manually input Moving 
UlC/FacIDs and monitor the status of facility comparison calculations. 

• Implement button controls for accepting, starting, resetting and exiting the 
application. 

• Implement a menubar and toolbar that allows the user to manipulate the 
COTS products in accordance with user requirements. 

• Provide feedback to user in the form of a statusbar and a selected facility 
information view. 

(2) RAD-based. A second analysis prototype used a 
combination of 4GLs, Delphi 2.0, Visual Basic and MapBasic, to develop a rapid 
application to audit and validate the USARC business rules and data logic for deriving 
the ARU-DM parameters. This was accomplished by creating relational database links to 
a subset of the data sources — Army Reserve Units in Pennsylvania — in their existing 
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format, computing the decision parameters in accordance with the business rules, and 
outputting the results to a common data file format (e.g.. Tab delimited). Additionally, a 
custom component was created and developed using the MapBasic spatial application 
development language; a programming language associated with interacting and 
automating the Mapinfo application. Essentially, the MapBasic component functioned as 
a workflow script that spatially selected the data necessary to calculate several decision 
parameters within a 50 mile radius. This proved to the collaborative team that the most 
critical aspect of the prototyping process, using USARC LAN files without modification 
and coordinating various heterogeneous COTS products, could be controlled by a 
common user interface. By prototyping ARIES in this way, we were able to obtain clear 
guidance on how to meet and comply with USARC’s unique military requirements and 
business rules. 



d. ARIES Conceptualization Artifacts 

Before proceeding to the next phase, a formal walkthrough review was 
conducted with all involved to ensure all user requirements had been gathered and the 
concept properly characterized. It was important to avoid “gold plating” the requirements 
(e.g., providing more functionality and features then the user needs) by realistically 
examining the application’s proposed concept and the organizations existing IS/IT 
infrastructure. The resultant ARIES artifacts of this phase were determined to be the 

following and are detailed in Appendix C: 

• Conceptual Overview Diagram 

• ARIES Process-Flow Diagram. 

• USARC Business Rules Specifications (Appendix B). 

• User Interface Interim Layout. 

• User Interface Final Layout 
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3. 



Visualization Phase 



Once the business issues are characterized and the application requirements have 
been defined, the next step is to turn these abstract requirements into an actual tangible 
architecture. The Visualization Phase does this by providing the means to synthesize the 
user requirements into functional architectures and component interactions. Unlike 
current software development practices, C2C does not attempt to clarify the difference 
between requirements and design. The goal is to facilitate the construction of the needed 
application using the most appropriate architectures. 

The C2C architecture design involves multiple levels of abstraction. At one 
extreme is the reference or domain-specific software architecture (DSSA); the other is the 
application architecture itself The DSSA represents the most general and abstracted 
form whereas the application architecture represents a specific design solution. In this 
phase, we categorize the two architectures as macro and micro. The macro-architecture 
illustrates the “what” and the micro-architecture illustrates the “how” of the application 
being designed. While the micro-architecture represents a specific technical solution and 
will change as the application is revised, the functional macro-architecture will remain 
the stable domain structure. Based on the requirements identified in the previous phase, 
the macro-architecture is partitioned into modules and the function(s) of each module are 
defined. The micro-architecture then entails the identification and selection of 
component software to fulfill theses functions. More simply, the micro-architecture key 
concerns are functionality and perfomiance; whereas the macro level concerns focus upon 
the management of complexity. 

One of the problems of identifying components is that future users of the 
application often view all of their processes as unique, and therefore desire custom-design 
components to handle this uniqueness. This is where a proper balance of “Buy -versus- 
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Build” strategy is needed by application developers; because some of the components 
may be available in the form of COTS products, and some components may have to be 
custom developed for the specific function they are required to implement. A good rule 
of thumb is “Build Business Value, Buy the Basics” (Knowles, 1997). Secondly, a 
component should be linked to an accepted standard and it must earn its way into the 
application architecture. The use of architectural styles such as these have several 
significant benefits: 

• Promotes design reuse within the problem domain. 

• Often leads to significant code reuse and shared implementations. 

• Enables better comprehension of the system’s organization if conventional 
structures are used. 

• Use of standardized styles supports interoperability. 

• Permits specialized analysis by constraining the design space. (Monroe, 1997, 
p. 45). 

We envision multiple passes through the Visualization Phase with the macro- 
architecture being solidified first, the U/1 in subsequent passes, and finally the component 
architecture (micro). Refinement occurs at each iteration with the end user closely 
engaged in the resultant architecture. 

a. ARIES Macro-A rch i lecture Stage 

Because SDSS was an innovative concept, there was no pre-existing 
reference architecture/DSSA upon which to base our design. With this in mind, the 
collaborative team utilized the artifacts from the previous phase and the BIA model to 

design a macro-architecture (Figure 3-6): 

• Point of Access (POA) Module - the prototyped U/1 

• Application Module - includes the ARIES Business rules and processes to 
capture the ARU-DM decision parameters and transfer them to the DSS. 
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• Technical Module(s) - includes the capabilities to display maps, spatially 
select data and provide decision support. 

• Information Module - includes the requisite data and business rules to support 
the mapping, decision parameter calculation, and decision support functions in 
the form of a Data Container. 




ARIES 

^RULES & PROCESSES‘ 



VISUAL BASIC 



^MAPINFO 



■DATA CONTAINER- 



Figure 3-6. ARIES Baseline Infrastructure Archetype (BIA) Model. 



VISUAL BASIC for APPLICATIONS 



(VBA) 



Because the movement of data between US ARC legacy data sources and 
SDSS modules has the largest data flows, the development team implemented a container 
approach to manage all data flows within the context of the macro-architecture (Figure 3- 
7). The Data Container represents an abstracted data repository that contains all the meta- 
data, source data and COTS support data necessary to the relocation decision, and 
provides a means for ARIES to be portable for mobile users and to operate independently 



52 




from the USARC LAN for networked users. Source data is migrated to a separate 

database structure (data migration warehouse — DataDepot) for the following reasons: 

• Provide an accurate, centralized, and high quality — data repository for 
calculating decision parameters. 

• Principle of minimality - only use whatever data is required to support reserve 
unit site selection. 

J 

• Accelerate data exchange between modules by using the native DBMS format 
of the USARC infrastructure. 




b. A RIES Micro- A rcit itecture Stage 



After considering a number of candidates and conducting an infrastructure 
review; the development team identified the primary technologies that fit the 
organizational objectives, with which to populate the macro-architecture (Table III). The 
information within the Data Container component represents the migrated USARC 
source data necessary to support the relocation decision analysis (DataDepot); the 
Mapinfo data files necessary to support the display of maps and geocoded information; 
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and the ARU-DM master templates to support the importation of computed decision 
parameters. 
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Application 
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(DataDepot) 
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Microsoft JE f SQL 
3.0 



Table III. Macro and Micro Architecture Comparison Chart. 



Interoperability between components can be achieved by a variety of 
means, but it must be delineated in the architectural framework and applied consistently 
throughout the application. In the case of ARIES, many various communication 
protocols had to be used to ensure proper component iteration. For example, because the 
LDW application was originally designed for a 16-bit Windows environment, it was 
incapable of being controlled via established distributed computing standards (e.g., OLE). 
Therefore, the development team used intrinsic Windows Application Programming 
Interface (API) routines to manipulate the LDW window displays and the Visual Basic 
SendKeys Function to process macro-scripts. In short, the ARIES U/I controls LDW by 
simulating a user’s input. 
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c. 



ARIES Donut in Prototype 



Although each of the technologies brought strengths that USARC wanted 
to take advantage of, integration of the components into a coherent process that could be 
controlled from a single point soon became a formidable challenge. The developers were 
faced with the difficulty of minimizing the coupling and data transfer between the major 
components in order to maximize application performance. The first step — was for the 
development team to fully understand all of the components — including their design 
intentions, capabilities, strengths, weaknesses and external communication protocols. 
The second step — was to partition the U/I views of the analysis prototype into smaller 
segments and put the riskiest parts at the top of the prototype list, rather than letting them 
slip to the end. This “Piece-of-the-Pie” or subset approach, allowed the developers to 
bind each U/1 view in turn to the applicable component (Table IV). 

By using RAD prototyping, the development team was able to build the 
interface quickly and easily using a visual development methodology (VDM), and then 
using component-based development, to link the U/I to existing data sources, 
infrastructure and components to ensure connectivity. Later in the Implementation Phase 
the team would place the appropriate code for business rules and data manipulation 
behind the approved user interface. In this mamier, the abstract interface encapsulated, or 
hid, the actual system implementation from the end-users. The decision-maker can only 
view and access the system by way of this single point interface. 
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information Panel 


Maplntb databases 
US ARC databases 
(GeoCoded) 
DataDepot 


ODBC (FoxPro) 
Dbase III 


UP/DOWN 
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Info 


Facility Selection 
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Table IV. ARIES User Interface/Micro- Architecture Component Binding. 



d. ARIES Visiudization Artifacts 



Before proceeding to the irhplementation phase, another formal 
walkthrough review was conducted with all involved to ensure that the proposed 
procedural flows, component architectures, and U/I prototype were practical, close to 
what the user expected, and adhered to specified standards. Figure 3-8 illustrates the final 
approved component framework solution. 
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Figure 3-8. ARIES SDSS Component Framework Solution. 



56 







4 . 



Implementation Phase 



At this phase in the C2C process, the component architectures and user interface 
prototyped in the Visualization Phase are translated into source code in 3GL or 4GL 
syntax. If an RDBMS is involved, the database schema will generated and integrated 
with the final application. The purpose of the coding is to translate the detailed 
architecture design into computer language suitable for the designated operating 
environment. 

Prior to this stage the development team “must first agree on the processes and 
methodologies it intends to follow, and it must decide which of those processes are going 
to be followed religiously -- and which ones will be honored in spirit, but perhaps not to 
the letter of the law” (Yourdon, 1997). Once this has been decided, the tools and 
technology can be chosen — or rejected — accordingly. 

a. ARIES Development Methods, Techniques, and Strategies Stage 

Once the application has been designed in the form of interacting 
components, it becomes very easy to add new ones and scale up the functionality of the 
system or adapt the system to meet a design constraint. This was the case in ARIES for 
transferring the computed decision parameters to the decision support system. Because 
the LDW DSS is a 16-bit Windows application, it was incapable of reading Microsoft 
Access database files without a custom modification by LDW’s development team. The 
solution was to convert the Access data table to a format that LDW could import reliably. 
Component testing of the LDW DSS indicated that a Tab-Delimited format was the most 
suitable and that by using the Microsoft Excel spreadsheet component available in 
USARC’s infrastructure software suite, the information could be converted and imported 
quite easily using OLE communication protocols. 
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Another advantage of the approved component framework, was that once 
all the required components and interfaces had been specified, many of the coding 
activities could be performed in parallel as long as the input data necessary for the 
component was available. 

Once the allocations of system requirements to. ..software components has 
been made, parallel. ..software definition, design, and implementation 
activities are initiated. During these parallel efforts, the.. .development 
team must continuously cooperate and communicate to ensure that their 
implementations are compatible. This continued interaction is critical to 
the successful integration of the. ..software components. (USAF-STSC, 

1992, p. 20). 



b. ARIES Coding Stage 



The ARIES U/I and application was coded using the Visual Basic for 
Applications (VBA) language and standard structured programming techniques. Only 
one form was created during the Domain Prototyping phase which contains all the VBA 
objects and the integrated Maplnfo object of the ARIES U/I. The rest of the partially- 
compiled application is comprised of several VBA-coded files and one MapBasic 
program (Appendix D): 

• SUBMAIN.BAS - Initializes the ARIES U/I; Loads and connects COTS 
components to U/I; Displays the U/I. 

• UserInterface.FRM - Contains all procedures, business rules, and logic for 
controlling the ARIES U/I. 

• PublicDeclarations.BAS - A library module that initializes all public variables 
and constants; Contains the variables that represent the SQL business rules for 
calculating the ARU-DM decision parameters. 

• Library. BAS - A library module that contains all the procedures called by 
other procedures more than one time. 

• OLE Library. BAS - A library module that contains all the procedures 
supporting OLE communications between COTS components. 

• OLE Callback. CLS - An object class description necessary for communicating 
with the integrated Maplnfo component. 
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• MapBasic.BAS - A library module that initializes all public variables and 
constants for communicating with the integrated mapping component. 

• ARlESArch - A MapBasic program that spatially selects the desired data 
within 50 miles of the specified location and locates the closest Army Reserve 
support facilities. 

Code evaluation occurs during and upon completion of coding. It ensures 
that coding techniques are acceptable and that standards have been followed during the 
coding process. The evaluation was conducted by the development team and NPS 
advisors, using peer-review and informal walk-throughs in order to verify the code 
against the design, and to ensure compliance. 

c. ARIES SDSS Application 

The gain in performance of this spatially enabled DSS over its manual 
counterpart is formidable. A process that previously required weeks, can now be 
completed in minutes. The SDSS DSSA is very flexible and offers numerous ways of 
eliciting preferences and displaying results. The structure is adaptable enough that it can 
be easily expanded to include additional decision parameters, criteria, and improved 
decision models. 

Given the large number of components that must be centrally controlled 
by the U/I, and the intense database activity involved in calculating decision parameters, 
a local installation of the ARIES application at USARC Headquarters was recommended. 
The development team believed it was critical to perform this type of testing at the actual 
client site in order to best measure the application’s performance in an operating 
environment that could not be simulated at NPS. Since this was economically infeasible, 
the application was rigorously tested on the provided laptop computer, and the burden of 
network “beta testing” of ARIES was shifted to the USARC staff 
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D. SUMMARY 



Our experience in using C2C to help USARC develop the prototype and test the 
SDSS concept, indicates that this approach can have a major impact on the way users and 
developers collaborate on producing functional software. C2C’s structural approach and 
use of component based development techniques to incrementally build and deliver 
mission-critical applications, formalizes a process that was, until recently, overly 
complex and unwieldy. 

The C2C process puts an early emphasis on addressing a concept’s high-risk areas 
by rapidly prototyping a proof-of-concept version of the intended system that defines its 
specific component architecture. It does not assume a fixed set of user requirements at 
the concept inception, but allows for iterative refinement of the requirements as the 
project evolves. Changes are expected and accommodated. The main focus still remains 
the final software product and its quality, as measured by the degree to which it satisfies 
the user’s expectations. 

As component-based development becomes more widespread and focuses on 
architecture, the complexity of the distributed operating environment should wane. Until 
that occurs, component-based systems built by non-programmers will probably continue 
to be interconnected in an unstable “hodge-podge” fashion. The best way to improve the 
integration of these systems is to adopt an enterprise-wide, integrated architectural 
strategy that incorporates standards that act to limit the inherent complexity faced by 
users and developers. In this sense C2C acts as a technological “gap filler” between 
baseline infrastructure and target applications. 

As with any new software development process and modeling methodology, 
nothing works exactly right the first time out. The USARC -NFS innovative collaboration 
was no different. What appears to occur smoothly throughout the development of the 



60 



ARIES SDSS application, in retrospect was actually disjointed and haphazard as USARC 
and NFS personnel underwent a “learning experience” about merging component-based 
technologies with architectural thoughts and ideas. These “lessons-leamed” are what the 
next chapter is devoted to exploring in detail. 
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IV. LESSONS LEARNED. 



‘"‘'There is a point at which methods devour themselves." 

Frantz Fanon, Black Skins, White Masks, 1 952. 

tool knows exactly how it is meant to be handled, while the user of the tool can 
only have an approximate idea." 

Milan Kundera, 1978. 

^'"Reality is the murder of a beautiful theory by a gang of ugly facts." 

Robert L. Glass. 

“77?e only thing new in the world is the history you have not learned." 

President Harry S. Truman 



A. OVERVIEW. 



This Chapter examines some of the most critical lessons that the development 
team learned while constructing the ARIES application. It is by no means inclusive of all 
the lessons learned during the project, but rather a representative sample of the lessons 
related to component-based development. Each chapter section is presented in 
categorical form, beginning with users and analysis; application development; rapid 
prototyping, and component-based development. Each of the pertinent lessons related to 
a particular section is stated first and then discussed at length. 

B. CONCEPTUAL ANALYSIS AND THE USERS. 

• Because of software development’s inherent malleability, it is difficult to 
anticipate which requirements will be implemented easily and which will 
decimate the project. 

Deciding what to build and what not to build is the age old dilemma that faces all 
developers. Experience has proven that software requirements are the biggest 
impediment to properly engineering complex systems. Conventional as well as state-of- 
the-art software development practices have failed to make appreciable headway against 
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persistent and pervasive problems with requirements management (DON-NRL, 1996, p. 
1). Beyond this need for discipline, requirements are intrinsieally hard to define well. In 
an attempt to better manage requirements analysis, the development team countered with 
the Conceptualization Phase of the C2C Heuristic. By devoting crucial time and energy 
at the outset, we hoped to eapture, structure, and contain the sheer essence of the project. 
This could not occur without an equal give-and-take on the part of the intended users. 
Through the formation of a collaborative effort, whereby the group built a little and 
prototyped a lot, a productive synergy yielded stable requirements from which to design 
architectures and model the problem domain. The users specify the “what” of the 
problem and the developers focus on the “how” of the solution. This iteratively and 
multiplicatively leverages the users’ business knowledge in concert with the technical 
acumen of the developers. Using prototyping as the practical solution The cognitive 
layers and the feedback cycle of the C2C structure acts to progressively guide the 
collaborative ensemble en masse from high levels of abstraction to a specialized solution 
space. 

In the case of ARIES, the characterization stage and U/I prototypes were the most 
instrumental in building the application correctly the first time instead of enduring 
endless cycles of change management. The developers were able to understand exactly 
what the SDSS needed to perform, were able to communicate side issues and 
discrepancies in the language of the users, and used an architectural focus to provide a 
means for controlling the production of the final application (DON-NRL, 1996, p. 6). 

• The developer cannot understand the business rules and processes well 
enough. 

Most application generation languages do a good job effectively designing the 
user interface and providing the underlying support code to connect the U/I to the 
pertinent database(s). But it is the business rules and data processing logic that are the 
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heart and soul of a successful application and are the most difficult to automate. It was 
this understanding of the rules to which the NFS development team devoted a majority of 
its analysis efforts. By focusing early in the Conceptualization Phase on thoroughly 
comprehending and characterizing the exact rules and processes used by the USARC 
decision-makers, the team avoided extensive and unnecessary rework later in the 
implementation stages. Using process roadmaps and documented business rules, ARIES 
development became a straightforward exercise in prototyping the U/I, identifying the 
required SQL database operations, linking the Rules to the U/I, and linking the rules to 
the SQL. 

• Keep the user engaged in the collaborative process. 

ARIES’S intended users failed to adequately specify top level system 
requirements as quantitatively as possible, and developers failed to better elicit them. 
Too many trade-offs and design decisions were left to the developer. Conflict at 
structured walk-throughs occurred between the developer’s view of the design and the 
users’ unarticulated view. Large amounts of development time were lost in several C2C 
stages because of these discrepancies. 

Collaboratively prototyping in one room or meeting is difficult enough under the 
best conditions, but in the case of ARIES the development team resided at NFS in 
Monterey, California, while a majority of the time the users were at USARC headquarters 
in Atlanta, Georgia. Attempts to regulate the collaboration using email proved 
ineffective. A second problem in this arena involved the USARC LAN network software 
upgrade from Windows 3.1 to Windows NT which was not scheduled for completion 
until after product delivery. As a result, incremental prototype builds could only be 
alpha-tested by USARC decision-makers during the monthly progress meetings. Instead 
of stabilizing the design, the opposite outcome occurred as the prototype demonstrations 
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elicited user suggestions not anticipated by the developers. For example, the user wanted 
to be able to select the facilities for site relocation graphically using the mapping 
component. The development team mistakenly assumed that the map view should label 
the selectable nodes with its corresponding facility identifier (FacID). The Domain 
Prototype was built around this misconception, only to discover at the prototype 
demonstration that users had trouble “drilling down” through the map layers of the map 
view because they were in the habit of selecting facilities by the closest cities and towns 
rather than by FacID. 

• Identify who is responsible for software maintenance prior to development. 

One the biggest mistakes that can occur with regard to software development is to 
delay the selection of the software maintenance organization until after the development 
of the software application and data structure has begun. The developer may have 
deployed a superior application, but if is incompatible with existing infrastructures or 
unsupportable by the recipient organization’s IS support staff, then the program probably 
will not be used and likely “wither on the vine” from lack of support. The solution is to 
select the provider of the technical support prior to the commencement of application 

development. The IS support can be provided in one of two forms: 

• Externally by the software development team/organization, or 

• In-house or organically (i.e., by an organization of the Army). 

If an organic organization is selected, then the software tools and applications 
used for development must be provided to, and agreed upon, by the maintenance 
organization. In the case of ARIES, the initial Analysis Prototypes were developed using 
Borland’s Delphi 2.0 fourth generation language. Although the lead developer had 
experience with Delphi client-server environments, the USARC IS Staff were 
inexperienced and unfamiliar with the Delphi programming environment. Therefore 
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Delphi was summarily vetoed by the USARC IS Staff and two additional requirements 

were imposed in the second round of the Conceptualization Phase: 

• Both the ARIES Application and Administer must be developed in Microsoft 
Visual Basic 4.0. 

• All Visual Basic and MapBasic source code must be provided separately to 
USARC in an uncompiled form. 

This resulted in a six week loss of development time while the development team 
attended several professional Visual Basic workshops and redesigned the Analysis 
Prototype to comply with these new requirements. 

C. ARIES APPLICATION DEVELOPMENT LESSONS. 

• Small development teams are best. 

It is a fundamentally simple principle that if you want to limit the number of 
defects in a project, then limit the number of developers involved in producing the 
project. Good people produce good software (Yourdon. 1996, p. 28). The results from 
using a small team for the ARIES SDSS were better management, less coordination, and 
improved communication between both team members and users. By using a design 
heuristic, automated tools, and architectural structure, the development team was able to 
remain small in size (3-8 members), and reducing the amount of code to be written and 
tested. Small teams using modern tools, techniques, and user experience can achieve 
high levels of productivity. 

• Spatial selection, when properly implemented, can substantially reduce 
decision model parameter calculation response times. 

During the Visualization Phase, the domain prototype of the ARIES SDSS 
performed much more slowly than the collaborative team had anticipated. Some of the 
problems occurred because of overhead from complex SQL queries between the U/I and 
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the RDBMS. For example, calculating the available MOS’s from the closing Army 
Reserve units requires the following logic: 

Determine all the individuals assigned to Closing Units who live within 

50 miles of the Proposed Site having MOS’s matching a prospective 

Moving Unit’s requirement for a particular MOS. 

The example took nearly an hour to execute on a Pentium 120 MHz computer, 
regardless of the population density of the location. Even with performance tuning 
execution time was still about 40 minutes on average to perform the query. The solution 
was to utilize the specialized geographic processing capability of the Mapinfo component 
to spatially select only the database records within the 50 mile geographic boundary of 
the proposed site. This required obtaining a waiver from USARC to allow the 
development team to geocode the Army Reserve Unit personnel database (G18CWE) 
using the MARS Engine, to migrate the database, and to spatially enhance it and two 
others for geoquerying by ARIES. The performance gain from this technique was on the 
order of five to seven times faster (Figure 5-1). 

• Avoid design error propagation by adhering to a philosophy of “Daily Build 
and Smoke Test. ” 

When discussing software development in terms of incremental prototypes or 
iterative “builds,” one thinks of monthly or weekly milestones. This correlates to the 
business world and our daily lives as a “normal” production pattern. The trouble lies in 
the rapid changes that prototyping perpetuates; factor in concurrent development by team 
members, and you have a recipe for disaster when project assembly occurs in one month 
(e.g., “let’s put it together and see what works”). 
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Figure 4-1. Spatial Solution Diagram. 



Component-based development allows the developer to follow a different 
approach — the Daily Build and Smoke Test. This process can be used effectively for 
projects of any size or complexity and consists of developers, on a daily basis 
assembling, compiling, linking, building, etc., all the project components and code 
modules into a deliverable application and then testing to verify its basic operations. The 
team is not allowed to continue coding until the current “build” passes satisfactorily, and 
component failures can be attributed as the responsibility of the component creator. In 
this manner the developers start every day with a product that functions correctly, and 
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ensures that any defects that are present were induced within the last 24 hours. It is far 
easier to retrace an individual’s one day effort, than a team’s monthly effort. This 
prevents developers from unwittingly developing incompatible components and 
corrupting the overall design. 

Why is this so important? The process pays for itself by reducing the time- 
consuming development risks of low quality, integration failure, and poor progress 
visibility (McConnell, 1996, p. 405). Not only does the developer always have a 
deployable application, but the users, project managers, and other team members always 
have a daily status of what is complete and what needs to be added. Any problems which 
arise tend to be relatively small in nature and can be dealt with accordingly, rather than 
shifting into “crisis mode’’ to rework code following a monthly or quarterly project build. 
“The daily build is the heartbeat of the project. It’s how you know you’re alive” 
(McCarthy, 1995). 

• A strong, stable, and well-defined architecture prevents degeneration of 
design. 

It can be extremely difficult to maintain an application architecture as the 
development process unfolds. Over time, performance and delivery pressures can 
combine to blur the architectural design, resulting in unwanted degeneration of the 
structure at all levels. A “good enough” architecture may be the result of attempting to 
accommodate a given COTS component structure, but a standards-based architecture is 
critical to the development process. Quality architecture is more likely to influence a 
successful project than a given set of components. Component technology and good 
architecture need to be intrinsically related, otherwise architectural mismatch can occur 
(Garlan et. al., 1995, p. 18). Rapid prototyping can accelerate this mismatch unless a 
strict development discipline is enforced by the developers to rework and revisit all 
affected components after each prototyping cycle ends and during component integration. 
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A well-thought out architectural solution can be effectively and efficiently implemented 
in almost any language, environment, and infrastructure. 

D. RAPID PROTOTYPING LESSONS. 

• Decide up front whether the prototype is to be a 'Uhrowaway” or a full 
production system. 

A throwaway prototype or scaled-down model is used for feasibility exploration 
and proof-of-concept studies in which user requirements are incomplete and the system 
approach is uncertain. However, if a prototype is being constructed using known 
requirements, and only minor uncertainties remain regarding the system approach, then 
an evolutionary prototype can be built, in which some or all of the prototype is retained 
(Gordon and Bieman, 1995, pp. 85-86). Usually the throwaway is built first, with the 
developer proceeding quite rapidly as the user requirements are defined and the system 
architecture is confirmed. The downside is that, in its limited, scaled-down form, the 
prototype is usually incapable of being deployed as a full production system because so 
many shortcuts have been taken to illustrate whether something could be done. When the 
design specifications are complete, then it can be rewritten to fulfill a more flexible, 
scaleable, and extensible form. 

Originally ARIES was budgeted for a two-phased development: a stand-alone 
throwaway prototype, and a full production network-centric version. The network model 
was to be a three-tiered, fully object-oriented client-server application that would be 
Windows NT enhanced to maximize decision parameter calculation using remote OLE 
automation. Difficulties with this scheduled arrangement occurred when project funding 
was reprogrammed halfway through the C2C development cycle. This required a 
collaborative reorganization of the ARIES SDSS to enable the application to execute in 
the network environment without being optimized for it. 
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Conventional wisdom counsels that whether “[you] plan to throw one away; you 
will anyway,” (Brooks, 1 987) but often, in the interests of time and expense, a prototype 
will be retained in some form from the start. As developers we are not advocating one 
particular method over another, only that in the best interests of the collaborative design 
team, it is imperative to decide from the outset which one it will be. 

* The collaborative nature of prototyping requires more of the user’s time 
than he plans for. 

The challenge of managing a prototyping effort can be much more complicated 
than managing conventional software development. The difference stems from the heavy 
emphasis placed on providing the users what they want and need. This leads to modeling 
processes in new ways, which in turn requires near constant feedback to prevent wasted 
effort and trivial pursuits of unintended features. Sometimes this constitutes more 
feedback than the user is capable of providing. 

Because USARC could only review U/1 prototype once a month during their trips 
to NPS, user feedback tended to come very late in the prototyping cycle. This latency 
mecint constructive feedback came at a time when incorporating the changes incurred 
significantly higher costs. Changes in the user interface prototype at the end of each 
Visualization Phase walk-through twice resulted in an additional four weeks of design, 
testing, and unit integration. 

• Quick visual results encourages the user(s) to suddenly see possibilities 
where before they had only seen barriers. 

A striking phenomenon about visually-oriented prototypes is the uncanny ability 
to elicit Archimede’s “Eureka!” reactions from the pool of intended users. The potential 
end-user goes from a position of ‘i’ll know it when I see it,” to “if you can do that, then 
surely you should be able to do this?” It provides a sense of empowerment to the user 
and allows him to shape and envision the final system.. In practice however, this can only 
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occur after he has gained some experience from the system proposed by the developers 
(Gordon and Bieman, 1995, p. 86). As with every new unprecedented capability, there 
comes a dark side. The user’s hunger for more and more funetionality ean become 
insatiable without some outside restraint imposed by the development team. This may 
result in uncontrolled “requirements creep.” Because the prototype can so effectively and 
easily mirror the final system, the intended user(s) may have little sense of the relative 
costs and the diminishing marginal returns of adding functionality beyond the scope of 
the initial concept. In short, “perfection” becomes the enemy of “good-enough.” 

In this sense it is the duty of the developers to guide and assist the users in 
prototyping the final system around a reasonable bandwidth of the users’ stated goals. 
Their experience and objectivity are critical in knowing when to stop prototyping and 
start coding. Otherwise excessive gold plating may result in a great system that never 
gets built. 

• Using COTS products does not eliminate software maintenance. 

On the contrary, because the origin of installed components is external to the 
developers, software maintenance plays an even larger role than it does in conventional 
software product development. If a component is modified and the vendor releases a 
bigger and better version, as they always do, who then is responsible' for the care and 
feeding of the application? The vendor? The development team? The recipient 
organization? Secondly, if the developers use the product “as-is” and the vendor updates 
other components in the application architecture, who bears the brunt of the burden to 
ensure component compatibility? Each change in the implemented design requires a new 
version of the system to maintain the technical integrity of the application. Otherwise the 
incompatibilities become cumulative and propagate instability throughout the component 
architecture. 
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This was the case with LDW, the ARIES DSS component. As the other 
components received major product upgrades, including the operating system, the LDW 
DSS remained unchanged. Because of the unwillingness of the LDW vendor to migrate 
LDW to a 32-bit application, the burden of maintaining the ARIES product over the next 
18 months will become even more difficult without radical work-arounds to make a 16- 
bit program backwards compatible within a 32-bit component framework. As a result, 
the viability of ARIES will become less and less certain as USARC upgrades its 
infrastructure. 

In summary, you cannot simply build a component-based application and then 
forget about it. The more easily such an application is built, the more critical the 
maintenance effort needed over the application’s lifecycle. 

E. COMPONENT-BASED COMPUTING LESSONS. 

• Building custom components is really, really, hard. 

Do not be fooled by the component evangelists. It is very difficult and time 
consuming to build even simple components that work and communicate well with other 
components and applications let alone complex ones. In today’s dynamically complex 
event-based development environments, a developer must be able to anticipate every 
possible use and interaction a component could be expected to fulfill and undergo 
respectively. Many component building and application software packages have been 
created to address these issues, but testing components in infinitely diverse combinations 
is a Herculean undertaking. Further, using contemporary methodologies does not insure 
success; many dismally poor components have been produced using modem tools and 
techniques. High quality and reliability comes at a premium cost. It is far easier to buy 
and modify a well-designed COTS product than to develop and validate a custom built 
one. The challenge in doing this well is to know and understand thoroughly the available 
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off the shelf commercial products, because many of the problems encountered during 
implementation simply cannot be determined before integration begins. 

• The learning curve for mastering component-based application development 
is steep. 

It is important that, prior to using a particular component or fourth generation 
development language for developing a component-oriented application, the developers 
are comfortable and familiar with the product. One person cannot be expected to 
instantly master several different components well enough to be an effective and efficient 
developer while at the same time attempting to prototype the system. “Just in time 
learning” is insufficient to guarantee a stable design and is often a blueprint for disaster. 

• Component communication protocols are the weakest link in the 
development chain. 

Some components are capable of using open or de facto standards (e.g., OLE), 
some must utilize proprietary communication protocols (e.g., DDE), and others cannot 
operate with various components at all. In order to effectively implement the ARIES 
component framework, the developers were forced to use a combination of all three 
methods to achieve the desired functionality. This approach was not without its 
drawbacks, for the less ‘open’ the protocol, the less functional the implementation. For 
example, because LDW is incapable of importing most current file formats, Microsoft 
Excel had to be used to save the resultant scenario’s decision parameter matrix in a tab- 
delimited format that LDW could process; Visual Basic could not do that easily. This 
introduced another component in the architecture whose only function was to serve as a 
file transfer agent, a function which is not the component’s strongest suit. 

The Mapinfo component, on the other hand, fully embraces the de facto OLE 
standard and effectively documents the component’s interconnections. As a result, 
approximately ninety percent of the functionality within the Mapinfo application could be 
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done within an integrated map window. To similarly manipulate the LDW application, 
the ARIES U/I hypnotized it into executing user-simulated keyboard commands using 
Microsoft Windows API routines and macro scripts. Essentially the ARIES U/I tricked 
the program into thinking a user was present when he was not. This technique is strictly 
limited in that only about 20% of LDW’s capability could be controlled in this way by 
ARIES. 

• Use of Commercial-Off-The-Shelf (COTS) components can result in “dead 
code” solutions. 

In some cases the use of an appropriate or inappropriate component can result in 
some or most of the component’s functionality not being used (dead code). Essentially a 
large component with many capabilities may only be needed to provide a single function 
or a small subset of the original functionality. An example of this is the use of Microsoft 
Excel, a large and complex application for spreadsheet manipulations, which is used 
exclusively in ARIES to load the decision parameter matrix and save it in a different 
format. Similarly, MapInfo is used only for geoquerying and facility selection, in spite of 
its extensive thematic mapping capability. The resources that the mapping component 
consumes (e.g., 4 MB of random-access memory) are lost to other applications when only 
15% of the component is used. 

• COTS components are not all “open ” standard compliant. 

This was probably the hardest lesson the ARIES development team had to 
contend with, and is a major issue for anyone interested in pursuing component-based 
development as a solution provider. In the past components or small, specialized 16-bit 
applications were designed and built using proprietary standards combined with 
programmers’ idiosyncratic methods to achieve a certain level of performance. As 
operating systems have matured and become more sophisticated, components and 
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programs are able to take advantage of object libraries and infrastructure to achieve 
functionality. Yet openness is still measured by proprietary designs and consumer 
acceptance. Providing a uniformly understandable means for accomplishing tasks is key 
to limiting communication chaos and reducing risk within the application’s architecture. 
Without standardization and architecture, the process of integrating unique application 
components becomes extraordinarily complex. Since no single vendor has 
accommodated the entire range of infrastructure management needs, de facto standards 
have emerged. 

This is where the real trouble arises, for third-party components and updates from 
vendors are not exactly ‘plug and play’, and frequently have a tendency to be falsely 
documented. The integration of various component data formats and communication 
protocols can be very complex, and subtle “gotchas” within a component may render its 
role in the component framework null and void. Initially the development team tried to 
grab too much “off the shelf’ and hastily put it all together during the prototyping stages. 
This yielded mixed results — mostly bad. The team was so enamored by the prospect of 
a buy-and-integrate strategy that it failed to realize that some COTS products can only 
interact in accordance with its own set of standards, architectures, and design. Not all 
COTS products are universally pliable. They may require in depth analysis of their 
intended operating environments and structure. 

As an example, LOW is capable of screen capturing its various graphic analysis 
displays to the clipboard or a graphic file. The undocumented difficulty is that the 
“clipboard” was implemented by the programmer in C++ without using Windows native 
API routines. Additionally, the graphic file is the 16-bit Windows meta-file standard 
(WMF) that is supported by only a handful of programs (e.g., Microsoft PowerPoint). 
Therefore, the only method available to allow the user to personalize the standard reports 
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feature of the ARIES U/I was to implement another large “dead-code” component, like 
PowerPoint, to once again act as a file transfer agent for graphic analysis editing. 

Another difficulty emerges when trying to integrate new versions of existing 
components within the application’s architecture. The new version may have a different 
look-and-feel and require more memory, and/or previous data formats and protocols may 
no longer be supported. In any case, another C2C incremental cycle will need to be 
completed to ensure application compliance and functionality. 

The only way in which to make various disparate components operate together 
reliably is to adopt a strong single vendor infrastructure solution (Microsoft) and work 
within the confines and limitations inherent to the selected standards and architecture. 
Hopefully in the future, emerging software technologies will be developed and distributed 
as a new kind of component. A component that is functionally cohesive, based upon 
open standards, small in terms of complexity, and therefore capable of operating in 
conjunction with all other possible components and software applications. (Figure 5-2). 

F. SUMMARY. 

It is becoming increasingly clear that software development, which relies heavily 
upon component-based architecture, requires modifications to the traditional development 
methodologies. Although some of the lessons derived from ARIES were recurring 
themes of software developments lessons of the past recast in component-based form, 
others were unique to the particular technologies and methods used within the structured 
C2C paradigm. In the final chapter, we summarize the lessons learned from this SDSS 
exercise, and project how these can be adapted to future component-based development 
applications. 
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Figure 4-2. Component Evolution Diagram. 
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V. CONCLUSIONS AND FUTURE RECOMMENDATIONS. 



'''' Institutionalizing organization-M>ide decision-making processes and an 
architecture is the key to all of our information system development efforts. ..and 
our primary measure of success is impact on the bottom line.” 

Chief Information Officer (GAO, 1994). 

”It is generally very difficult to keep up with a field that is economically 
profitable, and it is only natural to expect that many of the techniques described 
here will eventually be superseded by better ones.” 

Donald E. Knuth, The Art of Computer programming, 1973. 

‘‘We build systems like the Wright brothers built airplanes — build the whole 
thing, push it off a cliff, let it crash, and start over again.” 

Professor R. M. Graham, Software Engineering, 1 969. 



A. INTRODUCTION. 



This chapter synopses the underlying themes characterizing the development and 
implementation of the ARIES SDSS. It summarizes our experience with using the 
Concept-to-Code (C2C) design heuristic to construct software within the context of a new 
structured paradigm, and provides suggestions and insight into the ARIES Next 
Generation (NEXGEN) prototypes. 

B. LOOKING BACK. 

Reflection upon the ARIES SDSS implementation could be perceived in one of 
two ways: as “blind luck”, a one-time-success story that by sheer happenstance delivered 
exactly what the user wanted with a development team that had no prior experience with 
the underlying development tools; or, in a more realistic light, as an application which 
provided a means to explore, justify, and demonstrate the validity of using component- 
based computing in conjunction with rapid application development techniques, to 
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quickly and accurately produce a scaleable, extensible, and useful decision support 
application. 

The C2C design heuristic employed for ARIES allowed the collaborative team to 
quickly conceive and sketch screens and displays, and then build the user interface up 
front in a short turnaround period. Defining how the components of the application 
architecture were to communicate with one another, drove how the intended functionality 
of the architecture was to be accomplished. The heuristic allowed the developers to 
“architect” the system into small components and put the high risk segments (e.g., 
primary functionality) at the head of the prototyping line, rather letting them slip to the 
end. It was important to build the most difficult components first and then add the “nice- 
to-haves” later on. C2C also greatly improved management oversight by allowing the 
application development process to be layered from a generic concept to specialized 
solution. 

In summary, the C2C process has resulted in a number of benefits: 

• Facilitated understanding of the development process by managers and 
programmers using a one-page graphical representation. 

• Provided concise, definable phases with clear entry and exit criteria and 
staged iterative development. 

• Fostered an atmosphere of continuous quality process improvement between 
users and developers. 

• Allowed small development teams to implement large scale, complex 
applications in short development cycles. 

• Provided clear communication of project status between the development 
team and management on a daily basis. 

The success of the ARIES SDSS could be considered surprising, but in reality it 
was no fluke. The C2C process, applied carefully, can lead to powerful applications 
within a surprisingly short period of time, months vis-a-vis years as in the case of ARIES. 
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Undoubtedly, C2C will continue to undergo experimental refinement and improvement, 
as it may very well become the mainstay of software application development. 

To date, the ARIES SDSS is effectively deployed on the USARC local area 
network, as well as USARC staff officers’ laptop computers. The results of the ARIES 
SDSS deployment have been very positive for both the NFS development team members 
and the USARC staff The issues of timely and consistent response to site relocation 
questions appear to be more than adequately met by the ARIES SDSS prototype. 

C. LOOKING FORWARD. 

1. Current Technology Options. 

a. Infrastructure: A Component Update 

In the short time since the deployment of the ARIES SDSS prototype on 
the USARC LAN, several changes have occurred with its primary components. All of 
the COTS infrastructure components, with the exception of Logical Decisions for 
Windows, have had new versions released by their associated vendors. Each 
component’s functionality has been greatly enhanced and conforms to widely accepted 
client-server protocols. This includes the Visual Basic development language, which has 
been significantly upgraded to function exclusively within the component-based 
paradigm. Applications created in Visual Basic 5.0 are now fully compilable and the 
ODBC component has been integrated into the new JET SQL 3.5 RDBMS engine. If 
ARIES code were migrated unchanged to the new 4GL environment, the user could 
expect to see an approximate 20% increase in program execution time and a dramatic 
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increase in non-native data processing time. This would also greatly reduce the time 
required to build the data migration warehouse from USARC’s FoxPro 2.0 data sources. 

Mapinfo and MapBasic have also been improved, however, the vendor has 
also created a separate integrated mapping component, called MapX, based on the 
Microsoft ActiveX standard. MapX allows developers to directly compile the desired 
mapping functionality with the prototyped application, thus eliminating the need for OLE 
communications between the two components. The integrated mapping features can now 
be “hardwired” directly into the ARIES U/I and would only need a fourth of the 
computer memory currently used by the Mapinfo application. 

b. ARIES DSS Component Redesign: The Need for Innovation 

The current version of LDW in its 16-bit format, is still more than capable 
of providing the required functionality, but as USARC upgrades its IT infrastructure to 
take advantage of future technology, the ARIES DSS component in its unscalable form, 
will eventually fail to provide effective decision support. What is needed is a new 
scaleable and extensible 32-bit DSS component. Currently, there are no vendors 
marketing DSS software with all of the functionality of the 16-bit LDW application (e.g., 
automatic waiting, dynamic sensitivity, etc.) The difficult choice is to either wait for 
market conditions to change, or custom develop a similar DSS component with the 
following additional features; 

• Allow the decision model to be directly manipulated within an integrated 
window on the ARIES U/I. 

• Allow decision-makers to graphically add or delete new decision parameter 
nodes, as well as fully document how they are calculated. 

• Create a Report Manager that allows the user to drag-and-drop various 
decision model graphs into standard documents (e.g., Microsoft Word, 
HTML, etc.) 
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c. 



Migrate Decision Making to the Web 



In order to take advantage of USARC’s upgraded Windows NT operating 
system and the continued focus on network-centric infrastructure; the competent 
developer can use the Visual Basic 5.0 component creation tool to build a new ARIES 
component that separates the USARC business rules and decision parameter calculations 
from the user interface. By using ActiveX technology, the ARIES SDSS can truly be a 
three-tier client-server application. The rules and processes could be changed, updated, 
or added separately from the ARIES U/I while still in accordance with corresponding 
changes in the ARU-Decision Model. Development time can now be better spent 
elsewhere instead of redesigning the U/I every time a business rule or condition changes. 

The new Visual Basic development language also allows the developer to 
“web-enable” any application quickly and easily from within the 4GL environment. The 
ARIES U/I could now be rapidly prototyped within a common development environment 
by the collaborative team in less time, using a web browser (e.g., Netscape Navigator or 
Microsoft Explorer) and a point-and-click web page designer (e.g., Adobe PageMill or 
NetFusion). This would allow ARIES to use more of USARC’s stabilized infrastructure, 
reduce the amount of software maintenance support needed, and reduce the number of 
languages and development tools that the application developer must leam. 

2. Future Technology Options. 

An important concern is how far the process of simplification of the user interface 
should go to provide easy access to spatial information without sacrificing necessary 
functionality. Prototyped software that enables site selection across space and time using 
a component-based infrastructure like the ARIES SDSS, has been created as one small 
step towards the continued development of spatial decision support systems. Thanks to 
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new component-based software tools, it is now possible to create compact, yet 
specialized web-based applications that allow inexperienced users to participate to a 
greater extent in solving local, spatially oriented problems as decision-makers rather than 
as programmers. This is all desirable as far as it goes, but without changes to other 
peripheral issues, the future capabilities of the ARIES NEXGEN can only advance so far. 
The USARC business processes related to site selection decisions are ripe for a 
concentrated reengineering effort that has the future in mind — Visioneering. 

a. Data Source Management 

The underlying data management philosophy of the NEXGEN SDSS is 
that the entire USARC network, local and remote sites, comprise a single, large virtual 
“Resources-to-Readiness” data migration warehouse. The decision-maker should be able 
to access any and every data source relating to site selection whether on an Army Reserve 
mainframe in Washington D.C., or a spatial data server on the local LAN; all from within 
the browser U/I. In today’s network-centric ecosystem, it makes good sense to use the 
web as an operating desktop since it is a logical interface that most users can quickly 
learn and understand. Essentially, the NEXGEN is a network user interface (NUI), 
whereby the user is able to seamlessly apply business rules and calculate decision 
parameters without having to have knowledge of where the data actually resides. 

The NUI will improve database processing by leveraging the flexibility of 
the web middleware to pull data simultaneously from all local and mainframe data stores 
using open standards. In short, web-based technologies act as a “data resolver” to 
connect decision-makers to information no matter where it is stored or how it is 
structured (Joch, 1997, p. 104D). 
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b. 



Decision-Maker Knowledge Management 



In order to adapt to the continuous turnover of military personnel at 
USARC headquarters, the NEXGEN SDSS needs to be able to interactively model and 
capture the corporate knowledge about various data sources, business rules, and ad-hoc 
queries residing in the minds of the decision-makers. When stored and replicated, this 
meta-data knowledge becomes a reusable resource that ensures a given decision analysis 
can be based on repeatable findings. In short, this means knowledge management 
through automation. 



c. Decision Parameter Derivation in Parallel 

Although new technologies and software are produced everyday, the 
appetite for higher application performance is never satiated. The sequential calculation 
of ARIES decision parameters using spatial selection was a superior solution for mobile 
decision-makers, but within the NT ecosystem, parallelism is an even better solution. 
The NT network supports this by near simultaneous launching of remote automated OLE 
server objects for decision parameter computations onto the network. In this scenario, 
the idle processors of any desktop computers attached to the network can be utilized to 
calculate all the decision parameters essentially in parallel. Depending on the amount of 
network traffic present, the entire decision parameter matrix could be hypothetically 
calculated in the same amount of time it now takes to complete just one complex decision 
parameter query. 

3. Future Scenario: The Final Episode. 

Users want to shape the technology that is implemented in their 
organization. They want to control its use and determine the effect it will 
have on their own work. They are rapidly understanding that their 
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effective use of technology coupled with a change in how they do business 
will determine their personal and organizational success. (Tapscott, 1993, 
p. 14) 

As component-based computing becomes more and more the norm for application 
development within civilian and military organizations, developing future IT decision 
support systems may become a far easier and user-friendlier process. Just ask Colonel 
McMurdo about his ARGIS 21 system: 

1721 HRS : “Hey Jack! That ARGIS 21 product is your responsibility, right?” It 
was Brigadier General Mark Rutherford, Col. McMurdo’ s immediate boss, on the phone. 
“Yes Sir,” the Colonel replied. 

“Well the Old Man just got a call about the BRAC situation on CNN. After that 
’stick-save’ at the hearing today, you’re stock is up 20 prestige points. As a matter of 
fact, you have a meeting with the Chairman and the other Four Stars in the Tank first 
thing tomorrow morning Seems they have big plans for ARGIS 21 concerning better 
force dispersion, limited over-the-horizon target selection, and real-time Joint logistics 
shipping status. You’d better bring that laptop of yours.” 

“I’m on it. Sir,” McMurdo responded, “and while I’m at it. I’d better give those 
people back at NFS a call. Looks like we’re going to be quite busy.” 
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APPENDIX A. ARIES SOURCE DATA FILE META-DATA. 



This appendix contains the meta-data that was documented for the ARIES SDSS 
prototype data source files. “ACROPOLIS” as used in this appendix refers to the file 
name of the ARIES data migration warehouse (DMW). 
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ARIES Data File Documentation Form 



ARIES File Name: AMSA Location: ../Aries/MapBasic/USARCData 

File Type: FoxPro 2.6 Size(MB): .026 No. Records: 190 

Associated ARIES Tables: Not in ACROPOLIS, Geocoded for use in Mapinfo 

File Description: 

AMSA File contains information about the location of each AMSA station. It is used in determining the 
value for the distance to the nearest AMSA. 



Required Data Elements 



Name 


Description 


Data 

Type 


Format 


Key 

Field 


facid 


Facility Identification Code 


Char 




No 


factitle 


Facility Title 


Char 




No 


fac_street 


Street Address of Facility 


Char 




No 


faccity 


City Facility is located in 


Char 




No 


fac_state 


State Facility is located in 


Char 




No 


faczip 


Zip Code of the Facility 


Char 




No 


abb_type 




Char 




No 
































































1 j 


1 


1 1 


1 



Extract Queries: 
NONE 
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ARIES Data File Documentation Form 



ARIES File Name: COMMAND PLAN Location; ACROPOLIS 

File Type: FoxPro 2.6 Size(MB): 3.29 No. Records: 9,897 

Associated ARIES Tables: CMDPLAN 



File Description: 

Command Plan is the file that contains information about each unit in the Army Reserve. It is used to 
cross reference FAC ID's with UlC's. It is also used to screen for Valid LHC's with in the next 13 months. 



Required Data Elements 



Name 


Description 


Data 

Type 


Format 


Key 

Field 


UIC 


Unit Identification. Code 


Char 




yes 


FACID 


Facility Identification Code 


Char 




no 


EDATE 


Effective Date of Transaction 


Char 




no 







































































































Extract Queries: 

CMDPLAN 

SELECT DISTINCT UIC, FACID AS FACJD, 
EDATE 

FROM COMMANDPLAN 
WHERE (FACID o "N/A") AND (FACID o 
"TBD") AND (FACID o "") AND 
(LEN(FACID) > 2) AND 
((LEFT(EDATE,4) = '1998' AND 
M1D(EDATE,5,2) <= '02') OR 
(LEFT(EDATE,4) <= '1997')) 
ORDER BY UIC, EDATE DESC 
INTO CMDPLAN 
INDEX ON UIC as UIC 
Note: Application automatically adjusts the 
dates to obtain a 13 month window. 
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ARIES Data File Documentation Form 



ARIES File Name: COMPLEX Location: ACROPOLIS 

File Type: FoxPro 2.6 Size(MB): 2.1 No. Records: 1,557 

Associated ARIES Tables: COMPLEX 



File Description: 

The Complex File is used to determine if the facility is owned by or leased to the government and the 
number of weekends each facility is used during a month. 



Required Data Elements 



Name 


De.scription 


Data 

Type 


Format 


Key 

Field 


FACJD 


Facility Identification Code 


Char 




yes 


GOVT_OWN 


Facility ownership status 


Char 


Y/N 


no 


RS_WKND_PM 


Reserve Station weekend usage per mo. 


Number 


0-4 


no 

















































































































Extract Queries: 

COMPLEX_ 

SELECT FACJD, GOVT OWN AS 

FAC_OWNED, RS_WKND_PM AS 
FAC_WKND_USED 
FROM COMPLEX 
WHERE LEN(FACJD) = 5 
INTO COMPLEX_ 

INDEX ON FACJD as FACID, Primary, Unique 
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ARIES Data File Documentation Form 



ARIES File Name: ECS Location: ...\MapBasic\USARCData\ 

File Type: FoxPro 2.6 Size(MB): ,004 No, Records: 30 

Associated ARIES Tables: Not in ACROPOLIS, Geocoded for use in Maplnfo 

File Description: 

ECS File contains information about the location of each Equipment Center, It is used in determining the 
distance to the nearest ECS, 



Required Data Elements 



Name 


Description 


Data 

Type 


Format 


Key 

Field 


facid 


Facility Identification Code 


Char 




No 


factitle 


Facility Title 


Char 




No 


facstreet 


Street Address of Facility 


Char 




No 


faccity 


City Facility is located in 


Char 




No 


facstate 


State Facility is located in 


Char 




No 


faezip 


Zip Code of the Facility 


Char 




No 


abbtype 




Char 




No 






























































1 


1 









Extract Queries: 
NONE 



97 



THIS PAGE LEFT INTENTIONALLY BLANK 



98 



ARIES Data File Documentation Form 



ARIES File Name: FINANCE Location: ACROPOLIS 

File Type: FoxPro 2.6 Size(MB): 83.4 No. Records: 311,793 

Associated ARIES Tables: F1NANCE_, FINANCE_QTR 

File Description: 

Finance is the file that contains pay information for the previous eight quarters about every Reservist. It is 
used to obtain information about Drill Attendance for a given Facility. 



Required Data Elements 



Name 


Description 


Data 

Type 


Format 


Key 

Field 


CURR_UIC 


Current Unit Identification Code 


Char 




No 


UTAIQCFY 


Unit Training Attendance for Qtr this FY 


Number 




No 


UTA2QCFY 


Unit Training Attendance for 2'"^ Qtr this FY 


Number 




No 


UTA3QCFY 


Unit Training Attendance for 3"^ Qtr this FY 


Number 




No 


UTA4QCFY 


Unit Training Attendance for 4“’ Qtr this FY 


Number 




No 


UTAIQIPF 


Unit Training Attendance for T' Qtr last FY 


Number 




No 


UTA2Q1PF 


Unit Training Attendance for 2"^^ Qtr last FY 


Number 




No 


UTA3Q1PF 


Unit Training Attendance for 3*^^ Qtr last FY 


Number 




No 


UTA4Q1PF 


Unit Training Attendance for Qtr last FY 


Number 




No 












































1 


1 


1 





Extract Queries: 

FINANCE_ 

SELECT "W" & LEFT(CURR_U1C,5) AS UIC, 
COUNT(CURR_UIC) AS 
UIC_TOTAL 
FROM FINANCE 
WHERE CURR_UIC o "" 

ORDER BY CURR_UIC 
GROUP BY CURR_UIC 
INTO FINANCE_ 

INDEX ON UIC as UIC 



F1NANCE_QTR 

SELECT "W" & LEFT(CURR_UIC,5) AS UIC, 

UTAIQCFY, UTA2QCFY, UTA3QCFY, 
UTA4QCFY, UTAIQIPF, UTA2Q1PF, 
UTA3Q1PF, UTA4Q1PF 
FROM FINANCE 

WHERE CURR_UIC o "" AND NPS_IND = NULL 
AND PAY_STAT = ’A' 

ORDER BY CURR_U1C 
INTO FINANCE_QTR 
INDEX ON UIC as UIC 
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ARIES Data File Documentation Form 



ARIES File Name: FPS Location: ACROPOLIS 

File Type: FoxPro 2.6 Size(MB): .088 No. Records: 1,561 

Associated ARIES Tables: FPS 



File Description: 

FPS is used to obtain information about the Cost to operate each facility as well as the Condition of each 
Facility. Used to return a value for the Cost per Square Foot and the Facility Condition. 



Required Data Elements 



Name 


Description 


Data 

Type 


Format 


Key 

Field 


FAC_ID 


Facility Identification Code 


Char 




No 


FAC_COND 


Condition of the Facility 


Char 




No 


COST_PR_SF 


Cost per Square Foot to Operate Facility 


Number 




No 










































































































1 







Extract Queries: 

FPS_ 

SELECT FACJD, FAC_COND, COST_PR_SF 

FROM FPS 

WHERE FACJD o 

ORDER BY FACJD 

INTO FPS_ 

INDEX ON FAC_1D as FACID, Primary, Unique 
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ARIES Data File Documentation Form 



ARIES File Name: FYxxLOSS Location: ACROPOLIS 

File Type: FoxPro 2.6 Size(MB): 85.4 No. Records: 260,000 

Associated ARIES Tables: FYxxLOSS, FYxxXFER 

File Description: 

FYxxLOSS file contains information about the personnel losses incurred by each unit during a fiscal year. 
It is used to determine the Average Loss and Transfer Rate of a Unit. 



Required Data Elements 



Name 


Description 


Data 

Type 


Format 


Key 

Field 


UIC 


Unit Identification Code 


Char 




No 


TRMN 


Transfer Reason Code 


Char 




No 



























































































































Extract Queries: 

FYxxLOSS 

SELECT UICl AS UIC, COUNT(UICl) AS 
UIC_TOTAL 
FROM FY_LOSS 
WHERE TRMN = 'LOSS’ 

ORDER BY UICl 

GROUP BY UICl 

INTO FYxxLOSS 

INDEX ON UIC as UIC, Primary, Unique 



FYxxXFER 

SELECT UICl AS UIC, COUNT(UICI) AS 
UIC_TOTAL 
FROM FY^LOSS 
WHERE TRMN = 'TRFD' 

ORDER BY UICl 

GROUP BY UICl 

INTO FYxxXFER 

INDEX ON UIC as UIC, Primary, Unique 
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ARIES Data File Documentation Form 



ARIES File Name: GI7 Location: ACROPOLIS 

File Type: FoxPro 2.6 Size(MB): 3.11 No. Records: 5,869 

Associated ARIES Tables: G 1 7Natl 



File Description: 

G17 file contains facility Unitname, street address data and Zip Code. It is used as the primary cross 
reference with Command Plan to display facility information and validate user input. 



Required Data Elements 



Name 


Description 


Data 

Type 


Format 


Key 

Field 


UIC 


Unit Identification Code 


Char 




No 


UNITNAME 


Name of the Unit 


Char 




No 


TCCCITY 


City Unit is located in 


Char 




No 


TCCSTATE 


State Unit is located in 


Char 




No 


TCCZIP 


Zip code of the Unit 


Char 




No 


TIER 


Code used to determine if Unit is closing 


Char 




No 


RECSTAT 


Recruiting Station Code 


Number 




No 


TYPEORG 


Type of organization 


Number 




No 































































Extract Queries: 

G17Natl 

SELECT UIC, UNITNAME, TCCCITY AS 
CITY, TCCSTAT AS STATE, 
LEFT(TCCZIP,5) AS ZIP, TIER 
FROM G17 

WHERE (RECSTAT o "I") AND (TYPEORG 
o "2") AND UIC o 
ORDER BY UIC 
INTO G17Natl 

INDEX ON UIC as UIC, Primary, Unique 
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ARIES Data File Documentation Form 



ARIES File Name: G18CWE Location: ACROPOLIS;. .\MapBasic\UsarcDat 

a 

File Type: FoxPro 2.6 Size(MB): 145.9 No. Records: 208,416 

Associated ARIES Tables: G18Natl, G18Natl_UlC; also Geocoded for use in Mapinfo 



File Description: 

G18 File contains information about personnel in the US Army Reserves. It is used in determining the 
Total Number Assigned used in calculating the Loss/Transfer Rates, Total Available Closing and the 
Reassignments values. Also used to obtain a list of the Zip Code’s and MOSs of every Reservists with their 
associated UlC.. 



Required Data Elements 



Name 


Description 


Data 

Type 


Format 


Key 

Field 


UlC 


Unit Identification Code assigned 


Char 




No 


ZIP 


Zip Code of the individual 


Char 




No 


PRI 


Primary MOS 


Char 




No 

















































































































Extract Queries: 

GlSNatl 

SELECT UlC, LEFT(Z1P,5) AS ZIPCODE, 
LEFT(PRI,3) AS MOS 
FROM G18_ 

WHERE PRl o "" AND UlC o "" 
ORDER BY UlC 
INTO G18Natl 
INDEX ON UlC as UlC 



G18Natl_UlC 

SELECT UIC, COUNT(UIC) AS UlC_TOTAL 

FROM G18Natl 

ORDER BY UlC 

GROUP BY UlC 

INTO G18Natl_UlC 

INDEX ON UIC as UlC, Primary, Unique 
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ARIES Data File Documentation Form 



ARIES File Name: G19TRUE Location: ACROPOLIS 

File Type: FoxPro 2.6 Size(MB): 14.4 No. Records: 233,211 

Associated ARIES Tables: G 1 9Natl 



File Description: 

GI9 File contains information about the required manning levels of each Unit. It is used in determining 
Average Area Manning for a Facility. 



Required Data Elements 



Name 


Description 


Data 

Type 


Format 


Key 

Field 


0WN_U1C 


Unit Identification Code 


Char 




No 




























































































































1 


1 : 


L -■! 





Extract Queries: 

G19NatI 

SELECT OWN_UIC AS UIC, 

COUNT(OWN_UlC) AS 
UIC_TOTAL 
FROM G19 
WHERE OWN UIC o "" 
ORDER BY 0WN_U1C 
GROUP BY 0WN_U1C 
INTO G19Natl 
INDEX ON UIC as UIC 
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ARIES Data File Documentation Form 



ARIES File Name: 



GEOREF 



File Type: FoxPro 2.6 



Location: ACROPOLIS;. AMapBasic\UsarcData 

Size(MB): .21 No. Records: 1,553 



Associated ARIES Tables: VALID_UNIT; also Geocoded for use in Mapinfo 



File Description: 

Georef File contains specific information about each Unit. It is used to verify and cross reference FACID's 
and UIC as well as Facility and Unit specific information. 



Required Data Elements 



Name 


Description 


Data 

Type 


Format 


Key 

Field 


FACJD 


Facility Identification Code 


Char 




No 


FAC_T1TLE 


Name of the Facility 


Char 




No 


FAC_CITY 


City the Facility is located in 


Char 




No 


FAC_STATE 


State the Facility is located in 


Char 




No 


FAC_ZIP 


Zip Code of the Facility 


Char 




No 


Latitude 


Position of Facility by degree of latitude 


Number 




No 


Longitude 


Position of Facility by degree of longitude 


Number 




No 









































































Extract Queries: 

VALID^UNIT 

SELECT FACJD, FAC_T1TLE AS 

UNITNAME, FAC_C1TY AS CITY, 
FAC_STATE AS STATE, 
LEFT(FAC_Z1P,5) AS ZIP 
FROM GEOREF 
WHERE FACJD o "" 

ORDER BY FACJD 
INTO VALID_UN1T 
INDEX ON FAC ID as FACID 
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ARIES Data File Documentation Form 



ARIES File Name: INTEREST Location: ACROPOLIS 

File Type: FoxPro 2.6 Size(MB): 4.2 No. Records; 3,985 

Associated ARIES Tables: INTEREST 



File Description: 

Interest File contains information about facilities and the date they were acquired. It is used to calculate 
the Facility Age for each facility.. 



Required Data Elements 



Name 


Description 


Data 

Type 


Format 


Key 

Field 


FAC_IDSTR 


Facility Identification Code 


Char 




No 


DATE_ACQ 


Date Facility Acquired 


Date 




No 


ABB_TYPE 




Char 




No 










































































































I 







Extract Queries: 

INTEREST_ 

SELECT FACJDSTR AS FACJD, DATE ACQ 
FROM INTEREST 

WHERE FACJDSTR o "" AND ABB_TYPE = 
"USARC (MB)” AND NOT 
ISNULL(DATE_ACQ) 

ORDER BY FACJDSTR 
INTO INTEREST_ 

INDEX ON FACJD as FACID, Primary, Unique 
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ARIES Data File Documentation Form 



ARIES File Name: IRR Location: ...\MapBasic\UsarcData 

File Type: FoxPro 2.6 Size(MB): 7.5 No. Records: 140,077 

Associated ARIES Tables: Not in ACROPOLIS, Geocoded for use in Maplnfo 

File Description: 

IRR File contains information about the individuals listed in the Individual Ready Reserve. It is used to 
determine the value for IRR Available and Available MOS IRR. 



Required Data Elements 



Name 


Description 


Data 

Type 


Format 


Key 

Field 


ZIPC 


Zip Code for IRR Individual 


Char 




No 





































































































































Extract Queries: 
NONE 
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ARIES Data File Documentation Form 



ARIES File Name: NGNON CL Location: ...\MapBasic\UsarcData 

File Type: FoxPro 2.6 Size(MB): .64 No. Records: 3,673 

Associated ARIES Tables: Not in ACROPOLIS, Geocoded for use in Maplnfo 



File Description: 

NGNON_CL File contains information about the non-closing National Guard Units. It is used in 
determining the value for Competition. 



Required Data Elements 



Name ' 


Description 


Data 

Type 


Format 


Key 

Field 


UPC 




Char 




Yes 


ZIP 


Zip Code for National Guard Individual 


Char 




Yes 



























































































































Extract Queries: 
NONE 
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ARIES Data File Documentation Form 



ARIES File Name; QMA Location: ...\MapBasic\UsarcData 

File Type: FoxPro 2.6 Size(MB): 2.8 No. Records: 34,265 

Associated ARIES Tables: Not in ACROPOLIS, Geocoded for use in Mapinfo 



File Description: 

QMA File contains Census information. It is used in determining the value for Recruit Market for each 
Facility. 



Required Data Elements 



Name 


Description 


Data 

Type 


Format 


Key 

Field 


ZIP 


Zip Code 


Char 




No 


MWCAT12 


White Male Mental Categories 1 &2 


Number 




No 


MWCAT3A 


White Male Mental Category 3A 


Number 




No 


MBCAT12 


Black Male Mental Categories 1 &2 


Number 




No 


MBCAT3A 


Black Male Mental Category 3A 


Number 




No 


MHCAT12 


Hispanic Male Mental Categories 1 &2 


Number 




No 


MHCAT3A 


Hispanic Male Mental Category 3A 


Number 




No 









































































Extract Queries: 
NONE 
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ARIES Data File Documentation Form 



ARIES File Name: RPINFQDT Location: ACROPOLIS 

File Type: FoxPro 2.6 Size(MB); 14.3 No. Records: 47,159 

Associated ARIES Tables: FPINFODT_ 



File Description: 

RPINFODT is a file that contains information about the backlogged maintenance costs of each Facility. It 
• is used to determine the amount of backlogged maintenance is required at the given Facility. 



Required Data Elements 



Name 


Description 


Data 

Type 


Format 


Key 

Field 


FAC_ID 


Facility Identification 


Char 




No 


CWE_TOTAL 


Total amount of outstanding Maint. Actions 


Number 




No 



























































































































Extract Queries: 

RPINFODT_ 

SELECT FACJD, SUM(CWE_TOTAL) AS 
MAINT_COST 
FROM RPINFODT 
WHERE FACJD o "" 

ORDER BY FACJD 
GROUP BY FACJD 
INTO RPINFODT_ 

INDEX ON FACJD as FACID, Primary, Unique 
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ARIES Data File Documentation Form 



ARIES File Name: RZA Location: .. AMapBasic\UsarcData 

File Type: FoxPro 2.6 Size(MB): .16 No. Records: 1,793 

Associated ARIES Tables: Not in ACROPOLIS, Geocoded for use in Mapinfo 



File Description: 

RZA File contains information about the location of Recruit Stations. It is used to determine the distance 
to the nearest Recruit Station. 



Required Data Elements 



Name 


Description 


Data 

Type 


Format 


Key 

Field 


rsid 


Recruit Station Identification Code 


Char 




No 


name 


Recruit Station Title 


Char 




No 


zip 


Zip Code of the Recruit Station 


Char 




No 


latitude 


Position of Recruit Station by latitude 


Number 




No 


longitude 


Position of Recruit Station by longitude 


Number 




No 





























































































Extract Queries: 
NONE 
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APPENDIX B. ARIES BUSINESS RULES AND PROCESSES. 



This appendix contains detailed information about the calculation of each ARU-Decision 
Model parameter that was automated in the ARIES SDSS prototype application. The 
information includes a description of each decision parameter, the business rule used to calculate 
the associated value, base units, source files, associated data migration warehouse 
(ACROPOLIS) tables, query or queries involved in the calculation, a description of the yield 
curve, and a graph of the yield curves. “ACROPOLIS” is the file name for the ARIES data 
resource file. 

The term “in the area” in this Appendix is defined as being with in a 50-mile radius of the 
moving unit or proposed facility. 



Index 

Decision Parameter 1. Facility Backlogged Maintenance 127 

Decision Parameter 2. Facility Operating Costs 129 

Decision Parameter 3. Facility Age 131 

Decision Parameter 4. Facility Condition 133 

Decision Parameter 5. Facility Ownership 135 

Decision Parameter 6. Competition 137 

Decision Parameter 7. Average Area Drill Attendance 139 

Decision Parameter 8. Area Loss Rate 141 

Decision Parameter 9. Area Transfer Rate 143 

Decision Parameter 10. Area Average Manning 145 

Decision Parameter 1 1 . Distance to Nearest Recruit Station 147 

Decision Parameter 12. Available Transfers from Closing Units 149 

Decision Parameter 1 3 . IRR Available 151 

Decision Parameter 14. Recruit Market 153 

Decision Parameter 1 5 . Reassignments 155 

Decision Parameter 1 6. Distance to Area Maintenance Support Activity 157 

Decision Parameter 17. Distance to Nearest Equipment Concentration Site 159 

Decision Parameter 1 8. Facility Weekends Used 161 

Decision Parameter 19. Available MOS from Closing Units 163 

Decision Parameter 20. Available MOS IRR 1 67 
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Decision Parameter 1. Facility Backlogged Maintenance 



Definition; Facility Backlogged Maintenance provides the total dollar value of backlogged 
maintenance. This provides an indication of the initial investment required to 
correct the significant maintenance problems with a proposed facility. 

Calculation: The Backlogged Maintenance value is based upon the sum values for maintenance 
actions documented for each facility in the “CWE_TOTAL” field of the 
RPINFODT file. The summation is done during the data extraction phase. 

Maint_Cost[Sum of outstanding maintenance actions for a facility] 

Units: Dollars 



Source File: RPINFODT 



ACROPOLIS Table(s): RPINFODT_ 

Query: Maint_Cost 

SELECT MAINT_COST 
FROM RPINFODT_ 

WHERE RPINFODT_.FACID = ProposedFacility.FACJD 

Yield Curve: A linear relationship is assumed between the backlogged maintenance costs and 
utility. Every dollar required or saved in this category is expected to have equal 
utility to a relocating unit. 




Max Utility: 0 Min Utility: > 1,000,000 



127 



THIS PAGE INTENTIONALLY LEFT BLANK 



128 



DECISION PARAMETER 2. Facility Operating Costs 



Definition; Facility Operating Costs provide an indication of the financial resources that are 
required to maintain the facility in a serviceable condition. This includes both 
utilities and minor maintenance costs. 



Calculation: Operating Costs are extracted from the “COST_PR_SF” field of the FPS file. 

COST_PR_SF[Retrieve the Cost per Square Foot for a facility] 

Units: Dollars per square foot per month 

Source File: FPS 



ACROPOLIS Table(s). FPS_ 

Query: COST_PR_SF 

SELECT COST_PR_SF 
FROM FPS_ 

WHERE FPS_.FACID = ProposedFacility.FACJD 

Yield Curve: A linear relationship is assumed between the operating costs and utility. Every 
dollar required or saved in this category is expected to have equal utility to a 
relocating unit. 




Max Utility: 0 Min Utility; >100 
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Decision Parameter 3. Facility Age 



Deflnition: This Decision Parameter indicates the age of the primary structure on the 

proposed relocation site. It is intended to reflect an assumed long term structural 
degradation with time. 

Calculation: Facility age is calculated based upon the acquisition date found in the INTEREST 
file. The acquisition date is compared to the current date and the difference is 
determined in months. 



DATE_ACQ[Current Year - Date Acquired] 



Units: Months 

Source File: INTEREST 



ACROPOLIS Table(s): INTEREST_ 

Query: DATEACQ 

SELECT DATE_ACQ 
FROM INTEREST_ 

WHERE INTEREST_.FACID = ProposedFacility.FACJD 
Yield Curve: A linear relationship is used between facility age and utility. 




Max Utility: 0 Min Utility: >1,200 
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Decision Parameter 4. Facility Condition 

Definition: Facility Condition is based upon a visual inspection of the structure and provides 

an indication of the serviceability of the primary structures. 

Calculation: This Decision Parameter is based upon the ISR part 1 rating entered in the 
“FAC COND” field oftheFPS file. 



FAC_COND[Retrieve Facility Condition] 
Units: No Units(Green, Amber, Red) 

Source File: FPS 



ACROPOLIS Table(s): FPS_ 

Query: FAC_COND 

SELECT FAC_COND 
FROM FPS_ 

WHERE FPS_.FACID = ProposedFacility.FACJD 

Yield Curve: The utility of these three categories varies in discrete steps. A facility that is 
categorized as “green” is judged to be approximately twice a desirable as one that 
is assigned an “amber” rating. 




Max Utility: GREEN Min Utility: RED 
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Definition; 



Calculation; 



Decision Parameter 5. Facility Ownership 

This Decision Parameter indicates whether the facilities at a proposed relocation 
site are leased or owned. 

Facility Ownership is based upon the entry in the “GOVT_OWN” field of the 
COMPLEX file. 



GO VT OWN [Retrieve Ownership Status] 
Units: No Units(Yes/No) 

Source Data; COMPLEX 



ACROPOLIS Table(s): COMPLEX_ 

Query; GOVT_OWN 

SELECT GOVT_OWN 
FROM COMPLEX_ 

WHERE COMPLEX_.FACID = ProposedFacility.FACJD 

Yield Curve: Facilities that are owned by the government are preferred as relocation sites over 
those facilities that are leased. The owned sites are assigned the maximum utility 
value of 1.0, while leased sites are given a 0 utility score. 




Max Utility: Yes 



Min Utility: No 
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Decision Parameter 6. Competition 



Deflnition: This Decision Parameter provides an indication of the level of competition for 

potential reservists. It considers only Army Reserve and Army National Guard 
units in the area of the relocation site. 



Calculation; Competition is determined by the number of positions that must be filled by all 
other Army Reserve and Army National Guard (ARNG) units in the area of the 
proposed relocation site. For Army Reserve units, the number of required 
positions is determined by counting the number of records in the G19TRUE file 
associated with each UIC in the area. For ARNG units, the value is found in the 
“AUTH” field of the NGNON_CL file. 

NO_AUTH_NG [Number Authorized National Guard] + 

NO_REQD[Number Area Reservists Required] 

Units; Number of competing positions 

Source File; COMMAND PLAN, G1 7, G19TRUE, GEOREF, NGNON_CL 



ACROPOLIS Table(s); CMDPLAN, GlTNatl, G19Natl, VALID_UIC 



Query; Area-FACID List(MapInfo) 

SELECT FACJD INTO TempFACID 
FROM GEOREF 
WHERE Object Within ObjAreaBuffer 
ORDER BY FACJD 

(Note; ObjAreaBuffer is equal to 300 miles) 

VALID_UIC 

SELECT UIC, FACJD, UnitName, City, State, Zip 
FROM GIVNatl 

WHERE G I VNatl.UIC = AN Y (SELECT CMDPLAN.UIC 

FROM CMDPLAN) 



Area-UIC List 

SELECT DISTINCT UIC INTO AREA_UIC 
FROM VALID_UIC 

WHERE VALID_UIC. FACJD = ANY (SELECT AREA_F ACID. FACJD 

FROM AREA_FACID) 



NO_AUTH_NG(MapInfo) 
SELECT * INTO TempNGUnits 
FROM NON CLOS 
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WHERE Obj Within ObjAreaBuffer 



SELECT SUM(AUTH) “No_AUTH_NG” INTO Strength 
FROM TempNGUnits 

NO_REQD 

SELECT SUM(UIC_TOTAL) AS TOTAL_REQD 
FROM G19Natl 

WHERE G19Natl.UIC = ANY (SELECT AREA_UIC.UIC 

FROM AREA_UIC) 

Yield Curve: A linear relationship exists between the number of competing positions from other 
units and the utility of a relocation site. The level of no site utility in this 
Decision Parameter begins at 10,000 positions which is above the maximum value 
expected. 




Max Utility: 0 



Min Utility: > 10,000 





Decision Parameter 7. Average Area Drill Attendance 


Deflnition; 


This Decision Parameter indicates the fraction of reservists with satisfactory drill 
attendance for all existing units in the area of the proposed relocation site. Areas 
with a high fraction of satisfactory drill attendance are preferred relocation sites 
because units relocated to that area are assumed to perform similarly in drill 
attendance. 


Calculation; 


This Decision Parameter considers the last four quarters of data contained in the 
FINANCE file. After initial screening, the number of reservist with 21 or more 
drill periods for the year is divided by the total number of people who meet the 
screening. 

DRILL SAT [Number of reservists with > 2 1 drill periods in a year] 
DRILL_TOTAL [Number of reservists required to drill] 


Units: 


Ratio 


Source File: 


COMMAND PLAN, FINANCE, G17, G19TRUE, GEOREF 



ACROPOLIS Table(s): CMDPLAN, FINANCE_, FINANCE_QTR, GlTNatl, G19Natl, 

VALID UIC 



Query: 


Area-FACID List(MapInfo) 

SELECT FACJD INTO TempFACID 

FROM GEOREF 

WHERE Object Within ObJAreaBuffer 

ORDER BY FACJD 

(Note: ObJAreaBuffer is equal to 300 miles) 

VALID_UIC 

SELECT UIC, FAC_ID, UnitName, City, State, Zip 
FROM GlTNatl 

WHERE G1 TNatl.UIC = ANY (SELECT CMDPLAN.UIC 

FROM CMDPLAN) 

Area-UIC List 

SELECT DISTINCT UIC INTO AREA_UIC 
FROM VALID UIC 

WHERE VALID UIC.FAC ID = ANY (SELECT AREA_FACID.FACJD 

FROM AREA FACID) 
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FINANCE_CY 

SELECT UIC, COUNT(UIC) AS UIC_TOTAL INTO FINANCE_CY 
FROM FINANCE_QTR 
WHERE (Select Case) 

Case V' QtrFY 

(UTA 1 Q 1 PF + UTA2Q 1 PF + UTA3Q 1 PF + UTA4Q 1 PF) > 20 
Case 2"“ Qtr FY 

(UTA2Q1PF + UTA3Q1PF + UTA4Q1PF + UTAIQCFY) > 20 
Case 3^“ Qtr FY 

(UTA3Q1PF + UTA4Q1PF + UTAIQCFY + UTA2QCFY) > 20 
Case 4“' Qtr FY 

(UTA4Q1PF + UTAIQCFY + UTA2QCFY + UTA3QCFY) > 20 
GROUP BY UIC 
ORDER BY UIC 

DRILL-SAT 

SELECT SUM(UIC_TOTAL) AS TOTAL_SAT 
FROM FINANCE_CY 

WHERE FINANCE_CY.UIC = ANY (SELECT AREA_UIC.UIC 

FROM AREA_UIC) 



DRILL-TOTAL 

SELECT SUM(UIC_TOTAL) AS DRILL_TOTAL 
FROM FINANCE_ 

WHERE FINANCE_.UIC = ANY (SELECT AREA_UIC.UIC 

FROM AREA_UIC.UIC) 



Yield Curve; The utility of the average drill attendance rate increases linearly between the 
values of 0 and 0.6. Above that point, increases in the attendance rate result in 
diminishing returns. Values above 0.6 become increasingly uncommon. 



Utility 




Max Utility: 1.0 Min Utility: 0.0 
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Decision Parameter 8. Area Loss Rate 



Definition; This Decision Parameter indicates the fraction of reservists who left the reserves 
in the previous fiscal year, for all existing units in the area of the proposed 
relocation site. Areas with a low loss rate are preferred relocation sites because 
units relocated to that area will also experience low loss rates. 

Calculation: The number of losses to units in the area in the previous fiscal year is divided by 
the number of reservists currently assigned to these units. Losses are identified 
through the transfer mnemonic field (TRMN=”LOSS”) of the FyxxLOSS file. 
The number of assigned reservists is determined by counting all of the personnel 
records in the G1 8CWE file associated with each UIC in the area. 



NO_LOSS[Total Number of Losses in the last year] 
NO_ASSN[Total Number Reservists Assigned] 



Units; Ratio 

Source File; COMMAND PLAN, FYxxLOSS, G17, G18CWE, GEOREF 



ACROPOLIS Table(s); CMDPLAN, FYxxLOSS, G17Natl, G18Natl_UIC, VALID_U1C 



Query: Area-FACID List(MapInfo) 

SELECT FACJD INTO TempFACID 

FROM GEOREF 

WHERE Object Within ObjAreaBuffer 

ORDER BY FACJD 

(Note: ObjAreaBuffer is equal to 300 miles) 

VALID_UIC 

SELECT UIC, FACJD, UnitName, City, State, Zip 
FROM G17Natl 

WHERE G 1 7Natl.UIC = ANY (SELECT CMDPLAN.UIC 

FROM CMDPLAN) 



Area-UIC List 

SELECT DISTINCT UIC INTO AREA_UIC 
FROM VALID_UIC 

WHERE VALID_UIC.FACJD = ANY (SELECT AREA_FACID.FACJD 

FROM AREA_FACID) 



NO_ASSN 

SELECT SUM(UIC_TOTAL) AS TOTAL_ASSN 
FROM G18Natl_UIC 
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WHERE G1 8Natl_UIC.UIC = ANY (SELECT AREA_UIC.UIC 

FROM AREA_UIC) 



NO_LOSS 

SELECT SUM(UIC_TOTAL) AS TOTAL_LOSS 
FROM FYxxLOSS 

WHERE FYxxLOSS.UIC = ANY (SELECT AREA_UIC.UIC 

FROM AREA_UIC) 



Yield Curve: This function includes both concave and convex regions. The inflection point 
occurs at a loss rate of .33 and a utility of 0.5. Based on experience, a loss rate of 
one third per year was considered to be typical. Any loss rate below this value 
has relatively high utility, whereas loss rates above the inflection point quickly 
approach a utility of zero. 



Utility 




Max Utility: 0 



Min Utility: 1 
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Decision Parameter 9. Area Transfer Rate 



Deflnition; This Decision Parameter indicates the fraction of reservists who transferred to 
different units in the previous fiscal year for all existing units in the area of the 
proposed relocation site. Areas with a low transfer rate are preferred relocation 
sites because units relocated to that area will also experience low transfer rates. 

Calculation; The number of transfers in the previous fiscal year is divided by the number of 
reservists currently assigned to the unit. Transfers are identified through the 
transfer mnemonic field (TRMN=”TRFD”) of the FyxxLOSS file. The number of 
assigned reservists is determined by counting all of the personnel records in the 
G18CWE file associated with each UIC. 

NO_XFER[Total Number of Transfers in the last year] 

NO_ASSN[Total Number Reservists Assigned] 

Units: Ratio 



Source File: COMMAND PLAN, FYxxLOSS, G17, G18CWE, GEOREF 



ACROPOLIS Table(s): CMDPLAN, G17Natl, G18Natl_UIC, FYxxXFER, VALID_UIC 



Query: Area-FACID List(MapInfo) 

SELECT FACJD INTO TempFACID 

FROM GEOREF 

WHERE Object Within ObJAreaBufifer 

ORDER BY FACJD 

(Note; Obj AreaBuffer is equal to 300 miles) 

VALID_UIC 

SELECT UIC, FACJD, UnitName, City, State, Zip 
FROM GI7Natl 

WHERE G 1 7NatI.UIC = ANY (SELECT CMDPLAN.UIC 

FROM CMDPLAN) 



Area-UIC List 

SELECT DISTINCT UIC INTO AREA_UIC 
FROM VALID_UIC 

WHERE VALID_UIC.FACJD = ANY (SELECT AREA_FACID.FAC JD 

FROM AREA_FACID) 
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NO_ASSN 

SELECT SUM(UIC_TOTAL) AS TOTAL_ASSN 
FROM G18Natl_UIC 

WHERE G1 8Natl_UIC.UIC = ANY (SELECT AREA_UIC.UIC 

FROM AREA_UIC) 



NO_XFER 

SELECT SUM(UIC_TOTAL) AS TOTAL_XFER 
FROM FYxxXFER 

WHERE FYxxXFER.UIC = ANY (SELECT AREA_UIC.UIC 

FROM AREA_UIC) 

Yield Curve; This function includes both concave and convex regions. The inflection point 
occurs at a loss rate of .33 and a utility of 0.5. Based on experience, a transfer rate 
of one third per year was considered to be typical. Any loss rate below this value 
has relatively high utility (close to 1.0), whereas loss rates above the inflection 
point quickly approach a utility of zero. 




Max Utility; 0 



Min Utility; 1 
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Decision Parameter 10. Area Average Manning 


Definition: 


This Decision Parameter indicates the ability to fill the required positions. An 
average value is determined for all existing units in the area of the proposed 
relocation site. Areas with high average manning levels are preferred relocation 
sites because units relocated to that area will also experience high manning levels. 


Calculation; 


The number of reservists assigned to area units (based upon the number of 
personnel records in G18CWE file associated with each UIC) is divided by the 
number of required positions (based upon the number of positions in the 
G19TRUE file associated with each UIC). An average is calculated for all UIC’s 
in the area of the proposed site. 

NO_ASSN[Total Number Reservists Assigned] 

NO_REQD [Number Area Reservists Required] 


Units: 


Ratio 


Source File: 


COMMAND PLAN, G17, G18CWE, G19TRUE, GEOREF 



ACROPOLIS Table(s): CMDPLAN, G1 TNatl, G1 8Natl_UIC, G19Natl, VALID_UIC 



Query; 


Area-FACID List(MapInfo) 

SELECT FACJD INTO TempFACID 

FROM GEOREF 

WHERE Object Within ObjAreaBuffer 

ORDER BY FACJD 

(Note; ObjAreaBuffer is equal to 300 miles) 

VALID_UIC 

SELECT UIC, FACJD, UnitName, City, State, Zip 
FROM G17Natl 

WHERE G1 7Natl.UIC = ANY (SELECT CMDPLAN.UIC 

FROM CMDPLAN) 

Area-UIC List 

SELECT DISTINCT UIC INTO AREA_UIC 
FROM VALID_UIC 

WHERE VALID_UIC.FACJD = ANY (SELECT AREA_FACID.FAC JD 

FROM AREA_FACID) 
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Yield Curve: 



NO_ASSN 

SELECT SUM(UIC_TOTAL) AS TOTAL_ASSN 
FROM G18Natl_UIC 

WHERE G 1 8Natl_UIC.UIC = ANY (SELECT AREA_UIC.UIC 

FROM AREA_UIC) 



NO_REQD 

SELECT SUM(UIC_TOTAL) AS TOTAL_REQD 
FROM G19Natl 

WHERE G19Natl.UIC = ANY (SELECT AREA_UIC.UIC 

FROM AREA_UIC) 



It is desirable that area units be able to exceed their minimum manning 
requirements. All manning levels above 125% are considered to have maximum 
utility. Manning levels below this value drop off quickly in terms of utility. 




Max Utility: 1.25 Min Utility: 0 
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Decision Parameter 11. Distance to Nearest Recruit Station 



Definition: Distance to the nearest Recruiting Station provides one indication of recruiter 

effectiveness. 

Calculation; The straight-line distance from the proposed site to the closest recruiting station is 
calculated using a geocoded version of the RZA file. 

DIST_RZ A [Determine distance to nearest Recruit Station] 

Units: Miles 

Source Data: RZA 

ACROPOLIS Table(s): NONE 

Query; DIST_RZA(Maplnfo) 

SELECT * 

FROM RZA 

WHERE Obj Withing ObjDistanceBuffer into TempRZA 
(Note: ObjDistanceBuffer is equal to 300 miles) 

SELECT Distance((CentroidX(Obj), CentroidY(Obj), FacIDLat, FacIDLong, “mi”) 
FROM TempRZA 

ORDER BY Distance INTO TempRZA.Dist 

Yield Curve: The effectiveness of a recruiting station in filling positions at a reserve unit is 
fairly high if the two are within a half hour drive of each other. It is assumed that 
recruiters are most effective in the area close to their recruiting station and that 
reserve recruits must be located near the unit with which they will serve. A 
distance of 30 miles is assigned an average utility of 0.5. A small change in 
distance results in less change in desirability when the distance is very small or 
very large than it does when the distance is around 30 miles. 




Max Utility: 0 
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Min Utility: >100 
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Decision Parameter 12. Available Transfers from Closing Units 

Definition; This value indicates the total number of personnel assigned to closing units within 
50 miles of the proposed site. 

Calculation; A list of Unit Identification Codes (UIC’s) is created which contains only those 
units scheduled to close within 1 8 months. These units are identified by an entry 
of 5B in the “Tier” field of the G17 file. The number of potential transfers from 
closing units is calculated by summing the number of records in the G18CWE 
database for the closing units which are located in the area of the proposed 
relocation site. 

T0TAL_AVA1L [Total Number of Available Reservists from Area Closing Units] 

Units; Ratio 

Source File; COMMAND PLAN, G17, G18CWE, GEOREF, US_ZIPS(MapInfo) 

ACROPOLIS Table(s); CMDPLAN, G 1 7Natl, VALID_U1C 

Query; Area-FACID List(MapInfo) 

SELECT FACJD INTO TempFACID 

FROM GEOREF 

WHERE Obj Within objAreaBuffer 

ORDER BY FACJD 

(Note; objAreaBuffer is equal to 300 miles) 

VAL1D_UIC 

SELECT UIC, FACJD, UnitName, City, State, Zip 
FROM G17Natl 

WHERE G1 7Natl.UIC = ANY (SELECT CMDPLAN.UIC 

FROM CMDPLAN) 



Area-UlC List 

SELECT DISTINCT UIC FNTO AREA_UIC 
FROM VALID_UIC 

WHERE VALID_UIC.FACJD = ANY (SELECT AREA_FACID.FACJD 

FROM AREA_FACID) 



AREA_CLOS_UIC 
SELECT UIC 
FROM G17Natl 
WHERE G1 7Natl.TIER = “5B” 

AND G17Natl.UIC = ANY (SELECT AREA_UIC.UIC 
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FROM AREA_UIC) 



AREA_ZIPCODE(MapInfo) 

SELECT ZIP_CODE 
FROM US_ZIPS 
WHERE Obj Within obj AreaBuffer 
ORDER BY ZIP_CODE 

Area_G 1 8_ZIP(MapInfo) 

SELECT DISTINCT UIC, ZIPCODE, COUNT(UIC) AS UIC_TOTAL 
FROM GI8CWE 
GROUP BY UIC, ZIPCODE 
ORDER BY UIC, ZIPCODE 

TOTAL_AVAIL 

SELECT SUM(UIC_TOTAL) AS TOTAL_AVAIL 
FROM Area_GI8_ZIP 

WHERE Area_G 1 8_ZIP.UIC = ANY (SELECT AREA_CLOS_UIC.UIC 

FROM AREA_CLOS_UIC) 

AND Area_GI8_ZIP.ZIPCODE = ANY (SELECT AREA_ZIPCODE.ZIP 

FROM AREA_ZIPCODE) 

Yield Curve: The shape of this function assumes diminishing returns in the number of transfers 
available. Experience suggests that for an average unit of 100 people, 
approximately half have prior reserve experience and that approximately half of 
the people in a closing unit will be able to transfer their skills directly to a new 
unit. The value of the first 100 reservists increases at a nearly linear rate because 
they provide preferred fills for approximately 50 of the positions of the moving 
unit. A value of 100 personnel is assigned a utility of 0.9. The incremental value 
added by each additional person over 1 00 continues to drop until no marginal gain 
is expected over 500. 



Utility 




Max Utility: > 250 Min Utility: 0 
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Decision Parameter 13. IRR Available 



Deflnition: 

Calculation; 

Units: 

Source File: 
Query: 



Yield Curve: 



Individual Ready Reserve (IRR) Available is the number of IRR members living 
in the area of the proposed relocation site. This is a Decision Parameter of the 
size of the prior service market. 

A geographical query returns the total number of IRR members living within a 
specified distance of the proposed relocation site. This process requires a 
geocoded version of the IRR file. 

TOTAL_IRR[Total Number of Available IRR from the Area] 

People 

IRR 

Areal RR(MapInfo) 

SELECT ZIPC “ZIP”, LEFT$(PMOS, 3) “MOS” 

FROM IRR 

WHERE Obj Within objAreaBuffer 

AND ZIPC o and PMOS o 
ORDER BY ZIPC 

(Note: objAreaBuffer is equal to 300 miles) 

TOTALJRR 

SELECT COUNT(*) AS TOTALJRR 
FROM ArealRR 

For a typical unit of 100 people, it is assumed that approximately 40 positions 
could best be filled by IRR members. The recruiting rate for the IRR is 
approximately 1 percent, so an area that offers 4,000 IRR members is assigned an 
average utility of 0.5. Above this point, there are diminishing returns. The 
market begins to exceed the personnel demand of a moving unit and limited 
recruiting efforts become marginally less effective. The utility of smaller 
numbers quickly drops off because of the importance of this source of recruits. 




Max Utility; >10,000 Min Utility: 0 
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Decision Parameter 14. Recruit Market 



The Recruit Market Decision Parameter estimates the total number of males who: 

1 . live in the area of the proposed relocation site 

2. Would score in the top half on the Armed Forces Qualification Test (AFQT) 

3. Fall into the desired age group (17-29 years old) 

This Decision Parameter sums the entries for all mental categories 1 through 3A, 
and all ethnic groups for the zip codes of interest in the Qualified Military 
Available (QMA) file. The version of QMA used contains only the estimates for 
males within the age range of 17 to 29. 

TOTAL_MARKET[Total Non-Prior Service Personnel from the Area] 

Units: People 

Source File: QMA, US_ZlPS(MapInfo) 

ACROPOLIS Table(s): NONE 

Query: QMA(MapInfo) 

SELECT LEFT$(Z1P, 5) “ZIPCODE”, MWCAT12, MWCAT3A, MBCAT12, 
MBCAT3A, MHCAT12, MHCAT3A 
FROM QMA 

WHERE Obj Within objAreaBuffer 
ORDER BY ZIP 

(Note: objAreaBuffer is equal to 300 miles) 

AREA_ZlPCODE(Maplnfo) 

SELECT Z1P_C0DE 
FROM US_Z1PS 
WHERE Obj Within objAreaBuffer 
ORDER BY Z1P_C0DE 

TOTAL_MARKET 

SELECT SUM(MWCAT12+MWCAT3A+MBCAT12+MBCAT3A+ 
MHCAT12+MHCAT3A) AS TOTAL_MARKET 
FROM QMA 

WHERE QMA.ZIP = ANY (SELCET AREA_Z1PC0DE.ZIP 

FROM AREA_Z1PC0DE) 



Definition: 



Calculation: 
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Yield Curve: Approximately half of a typical unit of 100 reservists is filled by recruits with no 



prior service. Assuming a recruit rate of 0.25 percent, there must be at least 
20,000 people in the area of the proposed relocation site who meet all of the 
requirements stated above. This value is assigned a typical utility of 0.5. As the 
number increases, there are diminishing returns. The market begins to exceed the 
personnel demand of a moving unit and limited recruiting efforts become 
marginally less effective. 



Utilit; 




0 



People 



250,000 



Max Utility: > 250,000 



Min Utility: 0 
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Decision Parameter 15. Reassignments 

Definition: The Reassignments Decision Parameter indicates the fraction of the reservists 

assigned to the moving unit who currently live within a specified distance (50 
miles) of the proposed relocation site 

Calculation: This Decision Parameter is calculated by first determining all zip codes that lie 
within a specified distance of the proposed relocation site (based upon zip code 
centroid) and then identifying all reservists who both live within one of the 
identified zip codes (based upon the “ZIP” field of the G18CWE file) and are 
assigned to the moving unit (based upon the “UIC” field of the G18CWE file). 
Then the number available reassignments is divided by the total number of 
reservists assigned to the moving unit. 

TOTAL RESERVISTS [Total Number of Available Reservists from the Moving Unit] 
UIC_TOTAL[Total Number of Reservists Assigned Moving Unit] 



Units: Ratio 

Source File: G1 8CWE, US_ZIPS(MapInfo) 

ACROPOLIS Table(s): G18Natl 

Query: AREA_ZIPCODE(MapInfo) 

SELECT ZIP_CODE 
FROM US_ZIPS 
WHERE Obj Within objAreaBuffer 
ORDER BY ZIP CODE 



G18(MapInfo) 

SELECT UIC, LEFT$(ZIP,5) “ZIPCODE”, PRI “MOS” 

FROM G18CWE 

WHERE Obj Within obJGl 8Buffer AND PRI o 
ORDER BY UIC, ZIP 
INTO G18 

Area_G18_ZIP 

SELECT DISTINCT UIC, ZIPCODE, COUNT(UIC) AS UIC_TOTAL 
FROM G18 

GROUP BY UIC, ZIPCODE 
ORDER BY UIC, ZIPCODE 
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TOTAL_RESERVISTS 

SELECT SUM(UIC_TOTAL) AS TOTAL_RESERVISTS 

FROM Area_G18_ZIP 

WHERE Area_G 1 8_ZIP.UIC = MovingUnit.UIC 

AND Area_G18_ZIP.ZIPCODE = ANY (SELECT AREA_ZIPCODE.ZIP 

FROM AREA_ZIPCODE) 



UIC_TOTAL 
SELECT UIC_TOTAL 
FROM G18Natl 

WHERE G 1 8Natl.UIC = MovingUnit.UIC 

Yield Curve: The current location will always receive a utility score of 0.0 on this Decision 
Parameter. For relatively close relocation sites, this function was made to be 
convex, assigning high utility values to alternatives that are close to the current 
location. 




Total number of reservists 



Max Utility: 1.0 Min Utility: 0.0 
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Decision Parameter 16. Distance to Area Maintenance Support Activity 

Definition: Distance to the nearest Area Maintenance Support Activity (AMSA) is calculated 

as a proxy Decision Parameter for response time and support quality. 

Calculation: The straight-line distance from the proposed site to the closest AMSA is 
calculated using a geocoded version of the AMSA file. 

DIST_AMSA[Determine distance to nearest AMSA Site] 

Units: Miles 

Source Data: AMSA 

ACROPOLIS Table(s): NONE 

Query: DIST_AMSA(MapInfo) 

SELECT * 

FROM AMSA 

WHERE Obj Withing ObjDistanceBuffer into TempRZA 
(Note: ObjDistanceBuffer is equal to 300 miles) 

SELECT Distance((CentroidX(Obj), Centroid Y(Obj), FacIDLat, FacIDLong, “mi”) 

FROM TempAMSA 

ORDER BY Distance INTO TempAMSA.Dist 

Yield Curve: The desirability of a relocation site is relatively insensitive to small changes in 
distance for both close and distant AMSA sites. Little degradation in service is 
expected if the AMSA can have parts and technicians on site within a couple 
hours using a car or truck. It is possible that a trainer that breaks down in the 
morning may be operational for an afternoon training session. At approximately 
200 miles (assigned a 0.5 utility) it starts to become impractical to expect same 
day service and avoid an overnight stay. Eventually it becomes necessary to 
consider flying rather than driving which is likely to further reduce the 
responsiveness and effectiveness of the AMSA. 




Max Utility: 0 Min Utility: > 500 
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Decision Parameter 17. Distance to Nearest Equipment Concentration Site 

Deflnition; Distance to the nearest Equipment Concentration Site (ECS) provides an 
indication of the training time that must be used to travel back and forth. 

Calculation: The straight-line distance from the proposed site to the closest ECS is calculated 
using a geocoded version of the ECS file. 

DIST_ECS[Determine distance to nearest ECSJ 

Units: Miles 

Source Data: ECS 

ACROPOLIS Table(s): NONE 

Query: DIST_ECS(MapInfo) 

SELECT * 

FROM ECS 

WHERE Obj Withing ObjDistanceBuffer into TempECS 
(Note: ObjDistanceBuffer is equal to 300 miles) 

SELECT Distance((CentroidX(Obj), Centroid Y(Obj), FacIDLat, FacIDLong, “mi”) 
FROM TempECS 

ORDER BY Distance INTO TempECS. Dist 

Yield Curve: The desirability of an Equipment Concentration Site is relatively insensitive to 
small changes in distance fof both close and distant sites. Typically, a site that 
can be reached within an hour and ten minutes is not significantly less desirable 
than one that can be reached in ten minutes. An hour of one-way travel time is 
not normally considered to be excessive and allows for most of the time to be 
spent training on a one day training exercise. At approximately 60 miles 
(assigned a 0.5 utility) it starts to become impractical to expect useful training to 
be conducted on a day trip and avoid an overnight stay. Eventually it becomes 
necessary to consider flying rather than driving which is likely to further reduce 
the desirability of the ECS. 




Max Utility: 0 Min Utility: > 200 
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Decision Parameter 18. Facility Weekends Used 

Definition; Facility Weekend Usage provides the number of weekends per month that the 
facility is currently in use. This Decision Parameter treats a facility as a limited 
resource that is incrementally depleted as more units are assigned. Since most 
units require exclusive use of the facility one weekend every month, the number 
of weekends used normally corresponds to the number of units assigned and is 
typically limited to four. 

Calculation: This value is extracted from the “RS_WKND_PM” field of the COMPLEX file. 

WKND US ED [Retrieve Number Weekends Facility Used per Month] 

Units: Weekends per month 

Source Data: COMPLEX 

ACROPOLIS Table(s); COMPLEX_ 

Query: WKND_USED 

SELECT COMPLEX_.FAC_WKND_USED 
FROM COMPLEX_ 

WHERE COMPLEX_.FAC_ID = ProposedFacility.FACJD 

Yield Curve: Although some exceptions exist, a typical facility offers no utility to a relocating 
unit if all four weekends are already being used. Although most facilities with 
three units or less should be able to accommodate a new unit and might be viewed 
as having equal utility, other issues such as full time administrative space and 
available equipment storage space make a facility with fewer units currently 
assigned slightly more desirable. 




Max Utility: 0 Min Utility: 4 
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Decision Parameter 19. Available MOS from Closing Units 

Definition; This Decision Parameter provides the number of reservists from closing units in 
the area of the proposed relocation site who possess a Military Occupational 
Specialty (MOS) needed by the relocating unit. These people provide a preferred 
pool of trained and qualified recruits. 

Calculation; The number of personnel records (from the G18CWE file) that meet all the 
following requirements are counted; 

1. The reservist is assigned to a unit that is scheduled to close (a 
TIER=”5B” entry in the G17 file is used to produce a list of closing 
units). 

2. The reservist lives in a zip code in the area of the proposed relocation 
site. 

3. The reservist’s primary MOS is needed by the moving unit. 

If the three MOS groups with the largest number of members in the moving unit 
account for more than 50 percent of the total unit membership, then only those 
three MOS’s are considered. Otherwise all MOS’s required by the moving unit 
are considered as an MOS of interest. 

TOTAL_CLOS_MOS[Total Number of Available Reservists from Area Closing Units with 

MOS’s of Interest] 



Units; Number of people 



Source File: COMMAND PLAND, G17, G18CWE, GEOREF, US_ZIPS(MapInfo) 
ACROPOLIS Table(s): CMDPLAN, G17Natl, G18Natl, VALID_UIC 



Query; Area-FACID List(MapInfo) 

SELECT FACJD INTO TempFACID 

FROM GEOREF 

WHERE Obj Within objAreaBuffer 

ORDER BY FACJD 

(Note; objAreaBuffer is equal to 300 miles) 

VALID_UIC 

SELECT UIC, FAC_ID, UnitName, City, State, Zip 
FROM G17Natl 

WHERE GlTNatl.UIC - ANY (SELECT CMD_PLAN.UIC 

FROM CMD_PLAN) 
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Area-UIC List 

SELECT DISTINCT UIC INTO AREA_UIC 
FROM VALID_UIC 

WHERE VALID UIC.FACJD = ANY (SELECT AREA_FACID.FAC_ID 

FROM AREA_FACID) 



NoAssnxMOS 

SELECT MOS, COUNT(*) AS MOS_COUNT INTO NoAssnxMOS 
FROM GlSNatl 

WHERE G 1 SNatl.UIC = MovingUnit.UIC 

GROUP BY MOS 

ORDER BY COUNT(*)DESC 

MOS_TOTAL 

SELECT SUM(MOS_COUNT) AS MOS_TOTAL 
FROM NoAssnxMOS 

MOS_TOP3 

SELECT TOP 3 MOS_COUNT 
FROM NoAssnxMOS 

MOSJNTEREST 

IF MOS_TOP3/MOS_TOTAL < 50% 

SELECT MOS INTO MOSJNTEREST 
FROM NoAssnxMOS 
ORDER BY MOS 
IF MOS_TOP3/MOS_TOTAL > 50% 

SELECT TOP 3 MOS INTO MOS_INTEREST 
FROM NoAssnxMOS 
ORDER BY MOS 

AREA_CLOS_UIC 
SELECT UIC 
FROM GlVNatl 
WHERE G 1 TNatl.TIER = “5B” 

AND GlTNatl.UIC = ANY (SELECT AREA_UIC.UIC 

FROM AREA_UIC) 



AREA_ZIPCODE(MapInfo) 
SELECT ZIP_CODE AS ZIP 
FROM US_ZIPS 
WHERE Obj Within objAreaBuffer 
ORDER BY ZIP_CODE 
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G18(MapInfo) 

SELECT UIC, LEFT$(ZIP,5) “ZIPCODE”, PRI “MOS” 

FROM G18CWE 

WHERE Obj Within objGl 8Buffer AND PRI o 
ORDER BY UIC, ZIP 
INTO GI8 

Area_G18_M0S 

SELECT DISTINCT UIC, ZipCode, MOS, COUNT(UIC) AS UIC_TOTAL 
INTO Area_GI8_M0S 
FROM GI8 

GROUP BY UIC, ZipCode, MOS 
ORDER BY UIC, ZipCode, MOS 

Area_G18_ZIP 

SELECT DISTINCT UIC, ZIPCODE, COUNT(UIC) AS UIC_TOTAL 
FROM GI8 

GROUP BY UIC, ZIPCODE 
ORDER BY UIC, ZIPCODE 

TOTAL_CLOS_MOS 

SELECT SUM(UIC_TOTAL) AS TOTAL_CLOS_MOS 
FROM Area_GI8_MOS 

WHERE Area GI 8_MOS.MOS = ANY (SELECT MOS_INTEREST.MOS 

FROM MOSJNTEREST) 

AND Area_GI 8_ZIP.UIC = ANY (SELECT AREA_CLOS_UIC.UIC 

FROM AREA_CLOS_UIC) 

AND Area_GI8_ZIP.ZIPCODE = ANY (SELECT AREA_ZIPCODE.ZIP 

FROM AREA_ZIPCODE) 



Yield Curve: The shape of this function assumes diminishing returns on the number of transfers 
available. Experience suggests for an average unit of 100 people, that it is 
unusual to expect more than a third of the members to transfer from closing units 
with the proper MOS. Of the reservists in this category, only half typically 
transfer, so a value of 60 personnel is assigned a utility of 0.9. The incremental 
value added by each additional person over 60 continues to drop until no marginal 
gain is expected over 250. 
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Decision Parameter 20. Available MOS IRR 



Deflnition: This Decision Parameter provides the number of Individual Ready Reserve 

members who live in the area of the proposed relocation site and who possess a 
Military Occupational Specialty (MOS) needed by the relocating unit. These 
people provide a preferred pool of trained recruits. 

Calculation: The number of IRR members who possess an MOS needed by the moving unit 
and who live in the area of the proposed relocation site (based upon the zip code 
of their home of record in the IRR file) are counted. If the three MOS groups with 
the largest number of members in the moving unit account for more than 50 
percent of the total unit membership, then only those three MOSs are considered. 
Otherwise all MOSs required by the moving unit are considered as an MOS of 
interest. 

TOTAL_IRR_MOS[Total Number of Available Reservists from the IRR with MOS’s of 

Interest] 



Units: Number of People 



Source File: IRR,G18CWE 
ACROPOLIS Table(s): G 1 8Natl, 

Query: NoAssnxMOS 

SELECT MOS, COUNT(*) AS MOS_COUNT INTO NoAssnxMOS 
FROM G18Natl 

WHERE G 1 8Natl.UIC = MovingUnit.UIC 

GROUP BY MOS 

ORDER BY COUNT(*)DESC 

MOS_TOTAL 

SELECT SUM(MOS_COUNT) AS MOS_TOTAL 
FROM NoAssnxMOS 

MOS_TOP3 

SELECT TOP 3 MOS_COUNT 
FROM NoAssnxMOS 

MOSJNTEREST 

IF MOS_TOP3/MOS_TOTAL < 50% 

SELECT MOS INTO MOSJNTEREST 
FROM NoAssnxMOS 
ORDER BY MOS 
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IF M0S_T0P3/M0S_T0TAL > 50% 

SELECT TOP 3 MOS INTO MOSJNTEREST 
FROM NoAssnxMOS 
ORDER BY MOS 

IRR(MapInfo) 

SELECT ZIPC “ZIP”, LEFT$(PMOS, 3) “MOS” 

FROM IRR 

WHERE Obj Within objAreaBuffer and ZIPC o AND PMOS o “” 

ORDER BY ZIPC 
INTO IRR 

TOTAL_IRR_MOS 

SELECT SUM(UIC_TOTAL) AS TOTAL_CLOS_MOS 
FROM IRR 

WHERE IRR.MOS = ANY (SELECT MOS_INTEREST.MOS 

FROM MOSJNTEREST) 

Yield Curve: IRR members represent preferred recruits for less than half of the positions of a 
typical moving unit (approximately 40 out of 100) because of issues such as 
seniority and changes in the skills associated with an MOS. The success rate of 
recruiting IRR members is approximately 1 out of 100, so 4000 IRR members in 
the area of the relocation site are required to provide sufficient market to fill the 
40 positions. The value of 4000 is assigned the average utility value of 0.5. As 
the IRR market increases it exceeds the needs of the moving unit and makes the 
limited recruiting efforts marginally less effective. 




Max Utility: > 25,000 



Min Utility: 0 
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APPENDIX C. CONCEPTUALIZATION PHASE ARTIFACTS. 



This appendix contains the artifacts that were documented upon completion of the 
Concept-to-Code (C2C) Conceptualization Phase. 



Index 

1. Conceptual Overview Diagram 171 

2. ARIES Data Flow Diagram 1 73 

3. User Inteface Interim Layout 175 

4. User Interface Final Layout 177 
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Conceptual Overview Diagram 
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ARIES Process Flow Diagram 
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User Interface Interim Layout 
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User Interface Final Layout 
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APPENDIX D. ARIES SDSS CODE LISTINGS 



This appendix contains the detailed code listings of each Visual and Map Basic module 
that comprises the ARIES SDSS prototype application. 



Index 

Module 1. SUBM AIN PROCEDURE 181 

Module 2. SDSS USER INTERFACE 1 83 

Module 3. ARIES PUBLIC DECLARATIONS 213 

Module 4. ARIES PROCEDURES LIBRARY 221 

Module 5. OLE PROCEDURES LIBRARY 231 

Module 6. OLE OBJECT CLASS DEFINITION 239 

Module 7. MAPBASIC PUBLIC DECLARATIONS 243 

Module 8. SPATIAL SELECTION PROGRAM 257 
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Module 1. SUBMAIN PROCEDURE 



Purpose: Submain Procedure immediately executes upon ARIES application loading in 

memory. It is a standard Visual Basic initialization procedure. For the purposes 
of the ARIES SDSS, the procedure loads the splash screen for 30 seconds, 
initializes all OLE connections with Mapinfo components and displays the main 
SDSS User Interface form. 

Source Type: Visual Basic for Applications 

Source File: SUBMAIN.BAS 

Code Listing: 



Attribute VB_Name = ”Sub[1ain" 

Option Explicit 

'Allocate flodule Variables 
Public bValidUIC As Boolean 
Public bS(3L(3ueryDone As Boolean 
Public bLDUactive As Boolean 
Public bGE0REF_Ex is ts As Boolean 

Public briap(3ueryActi ve As Boolean 
Public btlapinf oRunni ng As Boolean 
Public bMapBasicRunning As Boolean 

Public iPropFacIDctr As Integer 
Public iProgressIndi cator As Integer 
Public is tatusBarflax As Integer 

'UinAPIBE window handles 
Public iLDUwinID As Long 
Public ihaplnf oUinID As Long 

Public aFacIIXM) As String * 5 

Public cflueryStartT ime As String * fi 
Public cProcName As String 

'Allocates Aries deasures Table 
Public cdovUic As Mo vi ngUni t_Type 

'Allocate Database Objects 
Public dbAcropolis As Database 
Public dbTeliko As Database 
Public dbUorkspc As Workspace 

Public objExcel As Object 
Public objGeoSelect As Object 
Public objGeofluery As Object 
Public objCallback As Object 



Public Sub dai n ( ) 

cProcName = '’SUB.dAIN" 

On Error GoTo EH_Subdain 
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Set objExcel = Nothing 
Set objGeoSelect = Nothing 
Set objGeo(2uery = Nothing 
Set objCallback = Nothing 

'Initialize all Boolean FLAGS to Default value- 
bValidUIC = False 

bLDUactive = False 'LDU Activation Flag 

bSt3L(2ueryDone = False 
bGEOREF_Ex i s ts = True 

bf1ap(2ueryActi ve = False 'HapBasic Activation Flag 

bflapBas i cRunn ing = False 
bflaplnf oRunning = False 

'Initialize API hWnd ID variables 
iLDUwinlD = 0 
iriaplnf oUinID = 0 

'Commence loading ARIES Application 
Load f rmSp 1 ashScrn 

'bLDUactive = OpenLDUob ject 
'Call ImportLDUdata 
'Call V i ewLDUmatr ix 

Exit Sub 

EH^SubMain: 'Submain Error Handler 

Select Case Err-Number 

Case ERR_0b jectUn 1 oaded 

Call Di splayHessage ( OLEf ailedflSG •» vbExclama ti on i vbOKOnlyi 
conOLEcapt ion ) 

End 

Case Else 'Trap all other Errors 8; Report 
Call 0utputERR0R_L0G 
Resume Next 

End Select 
End Sub 

Public Sub D i splayUserIn ter face ( ) 

cProcName = "Di splay_User_Interf ace” 

Uith f rmAr iesflain 
-Visible = True 
-UindowState = vbtlaximized 
• Show 
End Uith 

Screen - MousePointer = vbDefault 
End Sub 
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Module 2. SDSS USER INTERFACE 



Purpose: Contains all procedures, business rules, and logic for controlling the ARIES U/1 

Source Type: Visual Basic for Applications 
Source File: USERINTERFACE.FRM 
Code Listing: 



Attribute VB_Name = "f rmAri esflain” 
Attribute VB_Creatable = False 
Attribute VB_Exposed = False 

Option Explicit 

Private Sub mnuFOpen_Click ( ) 

Dim iU)U_hli)nd As Long 

On Error GoTo EH_FileOpen 



dlgLDlilFi ler . Flags = cdlOFNPathflustExist + cdlOFNFi leflustExist 
dlgLOUFiler • InitDir = App.Path & FILE_LDlil_Archi veDir 
dlgLDUFi 1 er • f i 1 ename = vbNullString 
dlgLDUFiler-ShowOpen 

iLI)li)_hli)nd = Findli) indow ( Class_LDU t vbNullString) 

If iLl)li)_hlJnd = D Then Call OpenLDUob ject 



ShowUindow iLDU^hUndi SliJ_n inimum 
Shou/li) indow iLDU^hUndi SU_Normal 



SendKeys 

SendKeys 

SendKeys 

SendKeys 

DoEvents 

SendKeys 

Exit Sub 



"‘/CFN"-. True 
"*/.F0 "t True 
dlgLDUFiler. 
"CENTER!"-. T 

"^CVn-"-. True 



filename-. True 
rue 



EH_F i leOpen : 



If Not Err-Number 



cdlCancel 



Then Call 0utputERR0R_L0G 



End Sub 



Private Sub mnuFSave_Cl i ck ( ) 

Dim iLDli)_hUnd As Long 

On Error GoTo EH_FileSave 

dlgLDUFi ler . Flags = cdlOFNPathflustExist 

dlgLDUFi ler . Ini tDir = App.Path & FILE_LDU_Archi veDir 

dl gLDUFi 1 er . f i 1 ename = vbNullString 

dlgLDUFiler. ShowSave 

iLDU_hUnd = Fi ndU indow ( Class_LDU -. vbNullString) 

If iLDU_hUnd = D Then Call OpenLDUob ject 

ShowUindow iLDU_hUndi SU_ninimum 
ShowUindow iLDU_hUndi SU_Normal 
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SendKeys ”>.FA"n True 

SendKeys dl gLDUF i 1 er • f i 1 ename n True 

SendKeys ”-CENTER}"n True 

DoEvents 

AppActivate ARIES_Appl ication 
Exit Sub 

EH_FileSave: 

If Not Err. Number = cdlCancel Then Call 0utputERR0R_L0G 
End Sub 

Private Sub mnuFCl oseLDU_Cl ick ( ) 

If Ver i f yLDlilob jectConnection (LDUacti vetlSG ) Then 
SendKeys ”^FX”n True 
DoEvents 

mnuVImport . Enabled = True 

tbararies . Buttons ("import" ). Enabled = True 
End If 
End Sub 

Private Sub mnuFC loseriap_Cl ick ( ) 

Dim iriapinf o_hUnd As Long 

iriapinf o_hUnd = FindU indow CClass_riapInf o t vbNul IStr ing ) 

If it1apInfo_hUnd = 0 Then 

Call Displaydessage ( APIf ailednSGi vbCriticaln vbOKOnlyi conAPIcapt i on ) 
Else 

bdaplnf oRunning = False 

ShowUindow idaplnf o_hUndT SU_dinimum 

ShowUindow idapinf o_hUnd t SU_Normal 

SendKeys "V.FX"n True 
End If 
End Sub 

Private Sub mnuFSe tup_C 1 i ck ( ) 

Dim iLDli)_hUnd As Long 

iLDli)_hlilnd = Fi ndU i ndow ( Class__LDU -» vbNul IStr ing ) 

If iLDli)_hliJnd = D Then Call OpenLDUob ject 

ShowUindow iLDU_hUndi SU_dinimum 
ShowUindow iLDU_hUndi SU_Normal 

SendKeys "V.FR"-» True 
End Sub 

Private Sub mnuFEx i t_C 1 i ck ( ) 

Call cmdEx i tBtn_Cl ick 
End Sub 

Private Sub mnuVHier_Cl ick ( ) 

If Not mnuVImport . Enabl ed Then 

If Veri f yLDUob jectConnection ( APIf ai leddSG ) Then 
SendKeys "*/:UB"t True 
SendKeys "‘/iHC downIG " t True 
End If 
Else 

Call Displaydessage (NoFacilityCompareddSG-i vbinf ormationi __ 
vbOKOnly-i conAPIcapt ion ) 

End If 
End Sub 

Private Sub mnuVdatr ix_Cl ick ( ) 
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If Verif yLDtilob jectConnectionC APIf ailednSC) Then 
SendKeys True 

DoE vents 
End If 
End Sub 

Private Sub mnuVSens i ti vi ty_Cl ick ( ) 

If Ver i f yLDlilob jectConnect ion ( APIf ai 1 ednSG ) Then 
SendKeys "^SY"t True 
End If 
End Sub 

Private Sub mnuVStackBar_Cl ick ( ) 

If Verif yLDWob jectConnection ( APIf ailednSG) Then 
SendKeys True 

DoEven ts 

SendKeys True 

End If 

End Sub 

Private Sub mnu VImport_Cl i ck ( ) 

If bS(3L(3ueryDone Then 

tbarar i es . Buttons ( ”impor t" ) • Enabled = False 
mnuVImport . Enabled = False 
f raLDblcntr 1 • V isible = False 

bLDlilactive = OpenLDblob ject 
Call ImportLDbldata 
Call ViewLDUmatrix 
Else 

Call Di splayflessage ( NoFaci 1 i tyComparednSG T vbinf ormation t _ 
vbOKOnly-i conAPIcapti on ) 

End If 
End Sub 

Private Sub mnuRPrintAl 1_C1 ick ( ) 

Dim ihsgBxResponse As Byte 

irisgBxResponse = D isplayhessage ( Pr interReadyflSG t vbExclamat ion -i 
vbOKi conAPIcaption ) 

If irisgBxResponse = vbOK Then 

If Ver i f yLDlilob jectConnect i on ( LDliIact i vetlSG ) Then 
Call TimeDelay (Time$ ( ) T B) 

Call Act ivateLDbJReports 
AppActivate ARIES_Appl icat ion 
End If 
End If 
End Sub 

Private Sub txtPropFacID_Change ( ) 

With txtPropFacID 

If (.Text = Or (Len(.Text) < 5) Then 

‘Text = .List(D) 

End If 
End With 

End Sub 

Private Sub cboUIC_Change ( ) 

With cboUIC 

If (.Text = Or (Len(.Text) < b) Then 

.Text = .List(D) 
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End If 
End With 



End Sub 

Private Sub cmd AcceptBtn_Cl ick ( ) 

Dim iFacIDctr As Byte 
Dim Index As Byte 
Dim i As Byte 

Dim iConf irmResponse As Byte 
Dim cflsg As String 

If bValidUIC Then 

iFacIDctr = CountFacIDs 
Fori=QTo3 

If txtFacID(i) .Tag = '’NOT USED'’ Then 
Index = i 
Exit For 
End If 
Next i 

If iFacIDctr < M Then 

tx tFacID ( Index ). Text = tx tPropFacID • Tex t 
Else 

cHsg = '’flaximum number of Facilities Selected.” S; vbCr 2 , vbCr 2 , _ 
”Do You Wish to Delete Facility I” 2 tx tFacID ( 3 ) • Te xt & _ 

’’If" 

iConf irmResponse = HsgBox ( cflsg t vb(3uestion + vbYesNoi 
conFacilityErrorCaption) 

If iConf irmResponse = vbYes Then 

tx tFacID ( 3) . Tex t = txtPropFacID . Text 
End If 
End If 

Else 

If Not cboUIC.Text = '’-NONE-” Then 
txtrio vUIC . Text = ’ cboUIC • Text 
Else 

cflsg = ”Facility I” & txtPropFacID & ”> has no Units Assigned.” 
Call Displayflessage (cflsgi vbExclamat ion t vbOKOnlyi conUICcaption) 
End If 
End If 
End Sub 

Private Sub cmdAr iesBtn_Cl ick ( ) 

Call Compare Fac i 1 i ties 
End Sub 

Private Sub cmdCl earBtn_Cl i ck ( ) 

'Reset all controls and elements of the User Interface to Defaults 

Call InitFacil ityElements 'Reset controls to Defaults 

Call InitflenuBar 

Call InitToolBar 

Call Ini t Ar i e sContro Is 

Call Ini tSta tusBar 

Call Ini tGIStreeview 

Call Traf f icLight ( vbRed) 

If Ar i esS tatusBar . Pane 1 s ( 5 ) . Tex t = ”Custom Tool • FacID Info” Then 
cmdAcceptBtn . Enabled = True 
End If 

bflapBasicRunning = False 
bS(3L(3ueryDo ne = False 

txtflo vUIC . Se tFocus 'Set cursor at flOVUIC txtbox 

Refresh 
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End Sub 



Public Sub cmdEx i tBtn_Cl ick ( ) 
cProcName = "Ex itBtn_Click" 

Dim iCon f irmResponse As Byte 'fISGBox Response Variable 

If bSflLflueryDone Then 

'Display Confirm CompactDa tabase flessagebox 
iConf irmResponse = MsgBox ( CompactDatabaseMSG t __ 

vbfluestion vbYesNo + vbAppl icat ionflodal t conFi 1 eCapt ion ) 

'Evaluate User Response 

If iConf irmResponse = vbYes Then 'Compact Database 
Call Compact Ari esDataBase 
End If 
End I f 

If Not ( ob jGeoSelect Is Nothing) Then 
ob iGeoSe 1 ect . SetCal Iback Nothing 
End If 

Set objGeoSelect = Nothing 
Set objCallback = Nothing 
Set objGeo(2uery = Nothing 
Set objExcel = Nothing 

Set dbAcropolis = Nothing 
Set dbTeliko = Nothing 

Unload fie 'Close User Interface 

End Sub 

Private Sub cmdYesBtn_Cl ick ( ) 

Call mnuVImport_Cl ick 
End Sub 

Private Sub cmdNoBtn_Cl i ck ( ) 

Dim iConf irmResponse As Byte 
Dim cfisg As String 

cfisg = "Do You Uish to Discard Facility Compar isonsf " 
iConf irmResponse = fIsgBox ( cfisg vbfluestion + vbYesNo-i conSCLcapt i on ) 
If iConf i rmResponse = vbYes Then 
f raLDUcntrl - Visible = False 
Call Ini tfleasuresGr id ( D ) 

Call cmdC 1 earBtn_Cl ick 
End If 
End Sub 

Private Sub sp i nFacIDbtn_Spi nDown ( ) 

Dim iComboBoxfIax As Integer 

Uith txtPropFacID 

iComboBoxfIax = *ListCount - 1 
If Not ( i PropFacIDctr = iComboBoxfIax) Then 
iPropFacIDctr = iPropFacIDctr + 1 
• Text = . List ( iPropFacIDctr ) 

Call LoadPropFacil i tyUICBox ( -Text) 

Call DisplayPropFacilityUnitNames 
End If 
End With 
End Sub 

Private Sub sp inFacIDbtn_Spi nUp ( ) 

Uith txtPropFacID 

If Not iPropFacIDctr = 0 Then 



187 



iPropFacIDc tr = i PropFacIDctr - 1 
•Text = . List ( iPropFacIDctr) 

Call LoadPropFacilityUICBoxC -Text) 

Call DisplayPropFacilityUnitNamGS 
End If 
End Uith 
End Sub 

Private Sub tbarAr iGS_ButtonCl ick (ByVal Button As Button) 



Dim iLDUhUnd As Long 'API window handler 

Dim iflsgBxResponse As Byte 'flessagebox response 


variable 


Select Case Button-Key 
Case "selector” 

ob jGeoSel GC t - RunflenuCommand f1_T00LS_S ELECT OR 
AriesStatusBar - Panels (S) • Text = "flapinfo Tool 


: Selector" 


Case "grabber" 

objCeoSelect. Runflenu Command f1_T00LS_RE CENTER 
AriesStatusBar . Panels (S) . Text = "flapinfo Tool 


: Grabber" 


Case "expand" 

objCeoSelect. Runflenu Command f1_T00LS_EXPAND 
AriesStatusBar . Panels (5) .Text = "flapinfo Tool 


: Zoom-In" 


Case "shrink" 

ob jGeoSe 1 GCt • RunflenuCommand f1_T00LS_SHRINK 
Ar i GsS tatusBar . Pane 1 s ( 5 ) • Text = "flapinfo Tool 


*- Zoom-Out" 


Case "infotool" 

ob jGeoSe 1 GC t • Do "Run Menu Command ID SOI" 





AriesStatusBar . Panels ( S) • Text = ^Custom Tool : FacID Info” 
pnlFaci 1 ityinfo . Enabled = True 
cboUIC ■ V i s ibl G = True 
cboUIC • Clear 

txtPropFacID « Visible = True 
txtPropFacID-Clear 
cmdAccep tB tn • Enabl ed = True 

Case ”mapinfo” 

If Not bHapInf oRunning Then 

iflaplnf obJinID = Shel 1 ( FILE_riapInf o t vbNormalFocus ) 

SendKeys True 

SendKeys ”/:FL”t True 

iflaplnf oUinID = Fi ndbJindow ( Class_riaplnf o t vbNul IString ) 

If i riaplnf oUi nID = □ Then 

Call D ispl ayflessage ( APIf a i 1 ednSG -I vbCriticali vbOKOnlyi _ 
conAPIcaption) 

End If 

briaplnf oRunni ng = True 
mnuFCloseHap • Enabled = True 
Else 

ShowUindow iflaplnf oU inID i SU_ninimum 
ShowUindow iflaplnf oU inID t SU_Normal 
SendKeys ”)lFX"i True 
bflaplnf oRunning = False 
mnuFCloseflap . Enabled = False 
End If 

Case "Idw” 

iLDliIhUnd = FindU indow ( Class_LDU i vbNul IString ) 

If iLDUhUnd = □ Then 

bLDUactive = OpenLDUob ject 
Else 

ifis gBxResponse = Displayflessage (LDUresetflSG-i vbfluestioni vbOKi 
conAPIcaption) 

If iflsgBxResponse = vbOK Then 
Call ResGtLDUob ject 
AppActivate ARIES_Appl ication 
tbararies • Buttons (”import” ). Enab led = True 
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f raLDUcntrl • Visible = True 
mnuVImport . Enabl ed = True 
End If 
End If 

Case "import" 

Call mnuVImport_Cl i ck 

Case "file" 

Case "report" 

Call mnuRPrintAl 1_C1 ick 

Case "matrix" 

Call mnuVUatr ix_Cl i ck 

Case "hierarchy" 

Call mnuVHier_Cl ick 

Case "dynamic" 

Call mnuVSensitivity_Cl ick 

Case "stacked" 

Call mnu VStackBar_C 1 i ck 

Case "about" 

End Select 
End Sub 

Private Sub cmdC 1 earBtn_Go tFocus ( ) 

'Display CLEAR button hint on main status bar 
AriesStatusBar • Panels ( 1) • Text = ClearBu ttonHSG 
End Sub 

Private Sub cmdAr i esB tn_GotFocus ( ) 

'Display GENERATE button hint on main status bar 
Ar iesS tatusBar . Pane Is ( 1) . Tex t = Launch Ari esHSG 
End Sub 

Private Sub cmdEx i tB tn_GotFocus ( ) 

'Display EXIT Button hint on main status bar 
Ar iesStatusBar - Panels ( 1) . Text = Ex i tButtonflSG 
End Sub 

Private Sub tx tHovUIC^GotFocus ( ) 

AriesStatusBar . Panels ( 1) . Text = HovUICs tatbartlSG 
End Sub 

Private Sub tx tFacID_GotFocus ( Index As Integer) 

AriesStatusBar • Panels ( 1) . Text = Faci 1 i tyStatbarHSG S; CStrCIndex + 1) 
Is tbxFacID ( Index ). Visible = True 
End Sub 

Private Sub t x triovUIC_Los tFocus ( ) 

If ( Len ( txtriovUIC) = □) And tx tHovUIC • Tag = "VALID" Then 
Call Traf f icLi ght ( vbRed ) 
bValidUIC = False 
txtnovUIC.Tag = "NOT USED" 

IstbxHovUIC-Clear 
End If 
End Sub 

Private Sub txtFacID__LostFocus ( Index As Integer) 

Dim iFacIDctr As Byte 
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VALID” Then 



If (Len ( txtFacID ( Index ) ) = 0) And txtFacID ( Index )• Tag = " 
txtFacID(Index) .Tag = ”N0T USED" 

IstbxFacIDC Index) -Clear 

IstbxFacID(Index) .Additem "* * DELETED * *" 

End If 

iFacIDctr = CountFacIDs 

If iFacIDctr = D And tx tflovUIC . Tag = "VALID" Then 
Call Traf f icLight(vbYellow) 

Elself txtnovUIC.Tag = "NOT USED" Then 
Call Traf f i cL i ght ( vbRed ) 

End If 
End Sub 

Private Sub txtFacID_Change ( Index As Integer) 

Dim bValidFacID As Boolean 
Dim bValidUnit As Boolean 
Dim cFacID As String * S 
Dim cflsgText As String 
Dim rs Val idateFacID As Recordset 
Dim rs Val idateUni t As Recordset 

CflsgText = "" 
bValidFacID = False 
bValidUnit = False 

'Open Validation Table 
Set rs Val idateFacID = dbAcropo 1 i s • OpenRecordset ( Tb l_Val i dateUIC i dbOpenTable-i 
dbReadOnly ) 

rs Va 1 i dateFacID . Index = "FACID" 

If bGEOREF_Exists Then 

Set rsVa 1 idateUn i t = dbAcropol is • OpenRecordset ( Tbl_Val idateUn i t i 
dbOpenTablei dbReadOnly) 

rsVal idateUni t • Index = "FACID" 

End If 

'Automatically determine if FACID entered 
If Len ( txtFacID (Index ) ) = 5 Then 
cFacID = txtFacID ( Index ). Text 

bValidFacID = Val idateFacID ( cFacID t rsVal idateFacID ) 

If bGEOREF_Exists Then 

bValidUnit = Val idateFacID ( cFacID i rsValidateUnit) 

End If 

If bValidFacID Or bValidUnit Then 'Valid FACID exists 

If bValidFacID Then 

Call LoadFaci 1 ityListBox ( Index T rsVal idateFacID -i □) 

Else 

Call LoadFaci 1 ityListBox ( Index 1 rsValidateUniti 1) 

End If 

aFacIDdndex + 1) = cFacID 
txtFacID(Index) .Tag = "VALID" 

If Not (Index = 3) Then 'Prep next Facility Frame 

Call InitializeFacil ityFrame (Index + 1) 

Call Traf f icLight ( vbGreen) 

Else 'Last Facility Frame used 

cmdAriesBtn.SetFocus 
End If 

Else 'Facility ID invalid 

cflsgText = "FacID: C" S cFacID S FacID inval idfISG 
Call Displayflessage ( cflsgText T vbinf ormation i vbOKOnlyi 
conFacilityErrorCaption) 

txtFacID ( Index ). Tex t = "" 
txtFacID ( Index ). Tag = "NOT USED" 

End If 
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Else 

Ari esStatusBar • Pane 1 s ( 1) • Text = FacIDlengthflSG 
End If 

'Delete Recordset Object 

rsValidateFacID- Close 

Set rsValidateFacID = Nothing 

rsValidateUnit- Close 

Set rsValidateUnit = Nothing 

End Sub 

Private Sub tx triovUIC_Change ( ) 
cProcName = ”TXTnOVUIC_CHANGE" 

Dim cHsgText As String 

cMsgText = 
bValidUIC = False 

If Len (txtnovUIC) = b Then 

chovUic-UIC = txtriovUIC . Text 
bValidUIC = Val idatehovUIC (cdovUic . UIC) 

If bValidUIC Then 

aFacID(D) = cHovU i c . FacID 
Call LoadHovUICl i stbox ( criovUic ) 

Call InitializeFacilityFrame(O) 
cmdCl earBtn • Enab 1 ed = True 
txtnovUIC. Tag = "VALID" 

'Set the appropiate data integrity light 
If Not txtFacID(O) .Tag = "VALID" Then 
Call Traf f i cLi ght ( vb Yel low ) 

Else 

Call Traf f icLight (vbGreen) 

End If 

Else 'Unit ID Code invalid 

cHsgText = "UIC: *C" & cHovUic-UIC & HovUICi n va 1 i dnSG 

Call Displayhessage (cHsgText T vbinf ormat i on i vbOKOnly-i conUICcapt ion ) 
txtnovUIC . Text = "" 
txtnovUIC. Tag = "NOT USED" 

End If 

Else 

AriesStatusBar . Panels (1) .Text = novUIClengthnSG 
End If 

End Sub 

Private Sub txtFacID_KeyPress (Index As Integeri KeyAscii As Integer) 

KeyAscii = KeyUpperNumer i c ( KeyAsc i i ) 

End Sub 

Private Sub txtnovUIC_KeyPress ( KeyAsc i i As Integer) 

KeyAscii = KeyUpperNumer i c (KeyAsci i ) 

End Sub 

Private Function CountFacIDs ( ) As Byte 

Dim i As Byte 'Loop Variable 

CountFacIDs = 0 'Initialize function 

For i = 0 To 3 'Loop thru Facility choices 

'Evaluate Facility Frame TAG field for Confirmed Selections 
If (txtFacID(i) -Tag = "VALID") Then 

CountFacIDs = CountFacIDs + 1 'increment counter 
End If 
Next i 
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End Function 



Private Sub Form_Load ( ) 

'Establish DEFAULT position for User interface 
He • Top = 0 
rie-Left = 0 

'Initialize Acropolis Database 

Set dbUorkspc = DBEng ine . liiorkspaces ( 0 ) 

Set dbAcropolis = dbUorkspc • OpenDatabase ( App . Path & FILE_Acropol i s ) 

'Set dbTeliko = dbUorkspc . OpenDatabase ( App . Path 8; FILE_Teliko) 

Set dbfleasures = Uorkspaces ( 0 )• OpenDatabase ( App . Path S; DB_riEASURES ) 

Set rsHeasures = dbfleasures - OpenRecordset ( "fleasure Values"i dbOpenTable) 
rsfleasures • Index = "FAC_ID” 

'Set rsProblems = dbfleasures • OpenRecordset ( ”Probl ems " t dbOpenTable) 

'Initialize the USER INTERFACE and Form Controls 
Call InitflenuBar 
Call InitToolBar 
Call Initflaps 

Call Ini tFaci 1 i tyinf oPanel 
Call Ini tFaci lityElements 
Call Ini tGIStreeview 

Call Traf f icLight ( vbRed) 

Call Init AriesControls 
Call Ini tStatusBar 

fie . Show 

fie - UindowState = vbfiaximized 
Refresh 

Screen . flousePointer = vbDefault 'reset mousepointer to arrow 

txtflovUIC • SetFocus 'set cursor at flOVUIC txtbox 

End Sub 

Private Sub InitializeFaci lityFrame (ByVal Index As Integer) 
cProcName = "INITI ALIZE__FACILITY_FRAf1E" 

If Not Index = M Then 

fraFacility (Index) -Enabled = True 
Uith txtFacID ( Index ) 

-Visible = True 
-Enabled = True 
- SetFocus 
End Uith 
End If 
End Sub 

Private Sub Ini tflenuBar ( ) 

cProcName = '’INIT_f1ENU_B AR” 

mnuVImport - Enabled = True 
mnuFCl oseLDU - Enabl ed = True 

End Sub 

Private Sub Ini tToo 1 Bar ( ) 

cProcName = "INIT_T00L__BAR" 

tbararies - Buttons ( "import" )- Enabled = True 
tbarar i es - Buttons ( "report" ) - Enabled = True 
tbararies -Buttons ("matrix") -Enabled = True 
tbarari es - Buttons ( "hi erarchy" )- Enabled = True 
tbararies - Buttons ("dynamic") -Enabled = True 
tbarar i es - Buttons ( "s tacked" )• Enabled = True 
End Sub 



'Initialize Default values 



'Display form to User 
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Private Sub InitHapsC) 

cProcName = "INIT.HAPS" 

Dim bflapSelectAct i VG As Boolean 

'Load riaplnfo Objects for Geofluery Display 

briaptJueryActi VG = ConnectOLEob ject (ob jGeo(3uery t ”f1apinfo • Application” ) 

If bflapCueryAct i VG Then 'Ensure Application loaded 

ob jGeoCuery . Do ”Set Application Window " S; p ictriap(3uGryFrame • hwnd 
ob jGeoCJuery . Do ”Set Next Document Parent " 2 . p i ctnap(3ueryFrame . hwnd & ” 
Style 1 ” 

End If 

'Load flaplnfo Objects for GeoSelect Display 

bMapSelect Active = ConnectOLEob ject ( ob jGeoSe lect i ”(1apinf o . Appl icat i on” ) 

If bflapSelectAct ivG Then 'Ensure Application loaded 

ob jGeoSelect • Do "Set Application Window ” g pictflapSelectFrame . hwnd 
ob jGeoSelect . Do "Set Next Document Parent ” & p i ctflapSe 1 ectFrame • hwnd & ” 
Style 1 " 

End If 

'Create an Instance of the OLE Callback Object 
Set objCallback = New c IsOLECal Iback 
objGeoSelect*SetCallback objCallback 

'Load & Display the flaps with labels 

Call OpenUS^S tatesLayer 

Call OpenUSARC_GeoRe f Layer 

Call OpenStateCapitalsLayer 

Call Openfla jorCi tyLayer 

Call DisplayflapLabels 

Call Positionflap 

'Modify the flaplnfo Right-Click Menu 
Call Initial izeflaplnfoflenu 
Call Ini tial izeflaplnf oToolbar 
Call Ini tial izeflaplnf oStatusBar 

'Set Zoom-In tool as the Default 
objGeoSelect-RunflenuCommand f1_T 00LS_EXPAND 
AriesStatusBar .Panels (5) -Text = "flaplnfo Tool : Zoom-In” 

Refresh 
End Sub 

Private Sub In i tfleasuresGr id ( By Val Index As Byte) 
cProcName = "INIT.ME ASURES_GRID” 

Dim i As Integer 

Dim iGridColumnWidth(conflaximumColumns) As Integer 
Dim cGridRowLabel (conTotalfleasures) As String 

'Load Column Width array 
iGridColumnWidth (□) = conOneColumnW idth 
iGridColumnWidth ( 1) = conTwoColumnW idth 
iGridColumnWidth (E) = conThreeCo lumnW idth 
iGridColumnWidth ( 3) = conFourColumnWidth 
iGridColumnWidth ( M ) = conFi veColumnW idth 



'Load Row Labels 
cGridRowLabel (□) 
cGr idRowLabel ( 1 ) 
cGr idRowLabel ( E ) 
cGridRowLabelO) 
cGr idRowLabel ( M ) 
cGr idRowLabel (5) 
cGridRowLabel ( t ) 
cGridRowLabelC?) 
cGr idRowLabel ( 6 ) 
cGridRowLabel (i) 
cGridRowLabel (ID) 
cGridRowLabel (11) 



array 

= confleasureD 
= confleasurel 
= confleasureE 
= confleasureE 
= confleasureM 
= confleasureS 
= confleasureL 
= confleasure? 

= confleasureS 
= confleasurel 
= confleasurelD 
= confleasurell 
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cGridRowLabel (12) 
cGridRowLabel(13) 
cGridRowLabel(lM) 
cGridRowLabel(lS) 
cGridRowLabel(lb) 
cGridRouLabeld?) 
cGridRowLabel(lfi) 
cGridRowLabel (1'^) 
cGridRowLabel(20) 



confleasurelE 

conf1easurel3 

confleasurelM 

confleasurelS 

confleasurelb 

confleasurel? 

confleasurelS 

confleasuren 

confleasureEO 



With gridfleasures 

'Establish Grid default parameters 
.Visible = True 
•Font. Size = S 



Reset Grid if data present 

Cols = 1 

Cols = 2 

FixedCols = 1 

FixedRous = 1 



'Set rows and columns- 

•Rows = 21 

•Cols = Index + 2 

'Set Fixed Column Label size 
.ColUidth(O) = 1370 

'Set remaining columns width dependent on number of Facilities 
For i = 1 To Index + 1 

. ColUidthC i ) = iGr idCo lumnWidth ( Index ) 

. Col A1 ignment ( i ) = 1 
Next i 



'Display Grid Row Labels in Column 1 
gr idfleasures . Col = □ 

For i = 0 To 20 

gridfleasures . Row = i 

gri dfleasures . Text = cGr idRowLabe 1 ( i ) 
Next i 
End Uith 
End Sub 



Private Sub In i t Fac i 1 i tyin f oPane 1 ( ) 

cProcName = ”INIT_FACILIT Y_INFO_PANEL” 

i PropFacIDctr = 0 

pnl Faci 1 i tyinf 0 . Enabl ed = False 
txtPropFacID . Vis ible = False 
cboUIC . Visible = False 
spinFacIDbtn . Vis ible = False 
Refresh 
End Sub 



Private Sub Ini tFac i 1 i tyEl ements ( ) 

cProcName = "INIT_FACILITY_ELEf1ENTS'’ 



Dim i As Byte 

cflovUic.UIC = "" 
cflovUic.FacID = 

tabAri esflap . Tab = 0 
tab Ari esUI . Tab = 0 

f raflovUIC.Tag = "NOT USED" 
f raflovUIC . Font . Size = 10 
txtflovUIC . Text = "" 
txtflovUIC . Enabled = True 



'Loop Variable 

'Set nOVUIC variable to NULL 



'Display GeoSelection flap 
'Display Facility Select Tab 

'Initialize Facility Frame TAGs 
'Set Font Size to default 
'Clear flOVUIC text box 
'Allow user input 
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IstbxnovUIC. Clear 



'Empty listbox 



For i = D To 3 

f raFac i 1 i ty ( i ) • Enabl ed = False 
f raFaci 1 i ty ( i ). Font . Size = T 
tx tFacID ( i ) . Tex t = "" 
txtFacID ( i )• Visible = False 
IstbxFacID(i) -Clear 
IstbxFacID ( i )• Visible = False 
txtFacID(i) -Tag = '’NOT USED" 
Next i 



'Loop thru Facility Frames 
'Disable Frame 
'Set Font Size to default 
'Clear facility text box 
'Hide facility text box 
'Empty facility list box 
'Hide facility list box 
'Set Frame TAG to default 



For i = 0 To M 

f raStatus ( i )• Enabl ed = False 
fraStatus ( i )• Font .Size = 10 
tx tSta tus ( i ) . Text = "" 
tx tS tatus ( i ) . V i s ibl e = True 
txtSta tus ( i ). Enabl ed = True 
IstbxStatus(i) -Clear 
1 stbxStatus ( i ). Visible = False 
aFacID(i) = "" 

Next i 



'Loop thru S(3L status frames 
'Disable status frame 
'Set frame font default 
'Clear status text box 
'Hide status text box 

'Empty status listbox 
'Hide status list box 



txtPropFacID-Clear 
cboUIC - Clear 
IstbxUnitName- Clear 
txtCity-Text = "" 
txtState - Text = "" 
txtZipCode - Text = " 



fraStatus ( MeasuresFrameIndex ). Enabl ed = True 



barS(3Ls tatus - Val ue = □ 
iProgressIndicator = D 
barS(3Ls tatus . flin = □ 

Refresh 
End Sub 

Private Sub In i tGIS treevi ew ( ) 

cProcName = "INIT_GIS_TREEVIEU" 



'Set progress bar to Zero 
'Set progress indicator default 
'Set Progress bar minimum 



trvGISData-Nodes-Clear 
trvGISData - Enabled = False 
Refresh 
End Sub 



Private Sub In i t Ar iesControl s ( ) 

cProcName = "INIT_ARIES_C0NTR0LS" 

cmdAri esBtn - Enabled = False 'Disable Pleasures Button 

cmdClearBtn - Enabled = False 'Disable CLEAR button 

cmdAcceptBtn - Visible = True 

cmdAcceptBtn - Enabled = False 'Disable ACCEPT Button 

cmdAcceptBtn - Enabl ed = True 
cmdAcceptBtn - Font - S ize = IE 
Refresh 
End Sub 

Private Sub In i tS tatusBar ( ) 

cProcName = "INIT_STATUS_BAR" 

AriesStatusBar - Panels (E ). Text = "" 

AriesS tatusBar - Pane 1 s ( 3 ). Tex t = "" 

Refresh 
End Sub 



Private Sub FormEl ementsLock (ByVal iFacIndex As Byte) 
cProcName = "F0Rn_ELEriENTS_L0CK" 

Dim i As Byte 'Loop Variable 

'Disable fluery and Clear user entry buttons 
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Call Traf f i cLi ght ( vbBlack ) 
cmdClearBtn . Enabled = False 
cmdAcceptBtn • Enab 1 ed = False 

tx trio vUIC • Enab 1 ed = False 
IstbxflovUIC • Enabl ed = False 

'Locks User input until fiuery finished 
For i = 0 To 3 

tx tFacID ( i ). Enabl ed = False 
IstbxFacID ( i )- Enabled = False 
Next i 

'Hides Exposed Facility Frame w/out User Input 
'If Not (iFacIndex = M) Then 
' txtFacID ( iFacIndex ). Visible = False 
' Is tbxFacID ( iFacIndex ). Visible = False 
' fraFaci 1 ity ( iFacIndex )• Enabled = False 
'End If 

'Bring Aries Measures Computation Tab to the Front 
tabAriesUI • Tab = 1 
Refresh 
End Sub 

Private Sub Ini t i a 1 i zeProgres sBar ( ByVal iFacIndex As Byte) 
cProcName = "PROGRESS_BAR_INITI ALIZE" 

Dim iProgressIndicator As Integer 

'Initialize Progress Bar 

iStatusBarflax = ((iFacIndex + 1) * conTotalfleasures ) -»■ „ 

((iFacIndex + 1) * conTotalInterimTables) + conSingleflessages 

iProgressInd icator = D 
With barS(3Ls tatus 
•Min = 0 
•Value = □ 

• flax = iStatusBartlax 
End With 

Refresh 
End Sub 

Private Sub D i spl ay(3ueryStartTime ( ByVal cStartTime As String) 
cProcName = "DISPL AY_(3UER Y_ST ART_TinE" 

With AriesStatusBar 

• Pane 1 s ( 1 )• Tex t = Launchflapinf oMSG 
ct3uer yStartT ime = cStartTime 

• Pane 1 s ( 2 ) • Tex t = "Start " S, c(3ueryStartTime 
End With 

Refresh 
End Sub 

Private Sub Di splayflueryEndT ime ( By Val c(3ueryEndT ime As String) 
cProcName = "DISPL AY_(3UERY_END_TinE" 

'Display (3uery End Time 
With Ar iesStatusBar 

• Pane 1 s ( E )• Text = "End " & c(3ueryEndTime 
Call E lapsedT imer ( c(3ueryEndTime ) 

End With 
Refresh 
End Sub 

Private Sub CompareFacil ities ( ) 

cProcName = "COMP ARE^FACILITIES" 

Dim i As Byte 
Dim j As Byte 
Dim iFacIDctr As Byte 
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'Loop Variable 
'Loop Variable 



Dim iConf i rmResponse As Integer 
Dim cAri esConf i rmflessage As String 
Dim bDupl icateFaci 1 ity As Boolean 
Dim bSi ng 1 eFaci 1 i ty As Boolean 
Dim aHeasuresCM) As rieasures_Type 
Dim rsFacilities As Recordset 

Set rsFacilities = dbAcropo 1 i s • OpenTable ( "V ALID_UNIT " t dbOpenTable) 

bDupl icateFaci 1 ity = False 
bSingleFaci 1 ity = False 

c Ari esConf i rmtlessage = AriesConf irmflSG & vbCr 
cHovUic-UIC = " " 

'Function determines the Total number of Facilities Proposed 
iFacIDctr = IDD 

'Determine if Proposed Facilities meet criterium (B minimum) 

'If iFacIDctr = D Then 
' bSi ng leFaci 1 i ty = True 
' Call In i tFaci 1 i tyE 1 ements 
' tx triovUIC - Text = cHo vUi c . Die 

'Else 'Check if Duplicate Facility Selected 

' For i = 0 To (iFacIDctr - 1) 

' For j = (i + 1) To iFacIDctr 

' If aFacID(i) = aFacID(j) Then bDupl icateFaci 1 ity = True 

' Next j 

' Next i 
'End If 

'Build Confirmation message 
'For i = □ To iFacIDctr 

' cAriesConf irmllessage = cAr iesConf irmflessage 8; Space(M) & aFacID(i) & " 
'Next i 

' cAri esConf i rmflessage = Left$ ( cAri esConf i rmflessage t 
(L en (cAriesConf irmflessage ) - D) 

cAri esConf i rmflessage = "This will conduct a calculation of the Valid 
Facilities in the Valid Unit List" 

'If bDup 1 i cateFaci 1 i ty Then 'Duplicate facility exists 

' Call Displayflessage (DuplicateFacilityflSGT vbCriticaln vbOKOnlyn 
conFacilityErrorCaption) 

'Elself bS i ng 1 eFac i 1 i ty Then 'Single facility exists 

' Call Displayflessage ( Inval idGIS(3uerynSG T vbCriticaln vbOKOnlyn 
conFaci 1 i tyErrorCaption) 

'End If 

If Not bDupl icateFaci lity And Not bS ing leFaci 1 i ty Then 
Sere en . flousePo i nter = vbHourglass 

i Conf i rmResponse = flsgBox ( cAriesConf irmflessage i vbCJuestion + vbOKCancel 
"Launch ARIES v3-D") 

If i Conf i rmResponse = vbOK Then 

Call FormEl ementsLock ( i FacIDctr ) 

Call Displayi3ueryStartTime(Time$() ) 

Call InitializeProgressBar(iFacIDctr) 

'Call Createf10S_InterestTabl e (cflovUic -UIC) 

Uith rsFacilities 
. HoveFirs t 

'Loop thru all proposed facilities 
For i = D To iFacIDctr 

afleasures ( i ) - FacID = - Fi e 1 ds ( "FAC_ID" ) • Va 1 ue 'aFacID(i) 

Call Ge tArchi vedFac i 1 i ty ( afleasures ( i ) -I cflovUic-UIC) 



If Not afleasures ( i )• Archived Then 



Call NonGIS(2uery (aMeasures( i ) ) 

' End If 

Call GIS(3uGry ( afleasures ( i ) ) 

Call ResGtSCL f names 

Call ArchivGFacilityneasures(aMeasures(i)) 

. Mo veNext 
Next i 
End Uith 

Call CloseGISfiuery 

Call DeleteTempAccessTables 

Call Display(3ueryEndTime(Time$()) 

* Call OutputComputedMeasunes ( afleasures () T iFacIDctn) 

tbaranies . Buttons ("import" )• Enabl ed = True 
cmdC learBtn . Enab led = True 
bS(3L(3ueryDone = True 
End If 
End If 

Screen - flousePointer = vbDefault 
End Sub 

Private Sub GetArchi vedFaci 1 i ty ( ByRef afleasures As f1easures_Type i ByVal 
cflovUic As String) 

cProcName = "Get_Archi ved_Faci 1 i ty" 

Dim rs A rchi vedFaci 1 i ty As Recordset 
Dim (3defnS(3L As String 

fidefnSCL = "Select * From Repository Where FAC_ID = »" & afleasures . FacID & 
Order by flOVUIC" 

AriesStatusBar .Panels(l) -Text = A rchi vedFaci 1 i tyfISG 
Refresh 

'Open Facility Respository Database 

Set rs A rchi vedFaci 1 ity = dbTel iko . OpenRecordset ( (3def nSCL t dbOpenSnapsho t t 
dbReadOnly) 

With rs Archi vedFaci 1 i ty 

If Tab leNotNULL ( rsArchi vedFaci 1 ity ) Then 
. flo veF irst 

Ar i esStatusBar * Pane 1 s ( 1 )* Text = LoadingArchi vefISG & !Fac_ID 
Ref resh 

'Transfer Facility Record to Measures table 
aMeasures • Archived = True 

Call D i sp layS tatus ( conMeasurel *> NonGISFrameIndex ) 
aMeasures . FacBack logdMaint = !FAC_MAINT 'Measure #1 

Call DisplayStatus (conMeasureEi NonGISFrameIndex ) 
aMeasures • Operati ngCost = !FAC_0PC0ST 'Measure 

Call DisplayStatusCconMeasureBi NonGISFrameIndex ) 
aMeasures ■ FacAge = !FAC_AGE 'Measure **3 

Call D i spl ayS tatus ( conMeasureM T NonGISFrameIndex ) 
aMeasures • FacCond = !FAC_C0ND 'Measure 

Call DisplayStatusCconMeasureSi NonGISFrameIndex ) 
aMeasures « FacOwned = !FAC_0WNED 'Measure #5 

Call DisplayStatus (conMeasurebi MeasuresFrameIndex ) 
aMeasures . Competi tion = !C0MPETI0N 'Measure 

Call DisplayStatus (conMeasure?! MeasuresFrameIndex ) 
aMeasures • AreaDri 11 Attend = !DRILL_ATND 'Measure 

Call DisplayStatusCconMeasureBi MeasuresFrameIndex ) 
aMeasures . AreaLossRate = !AREA_L0SS 'Measure 

Call DisplayStatus (conMeasure^T MeasuresFrameIndex ) 
aMeasures • AreaXferRate = !AREA_XFER 'Measure 

Call D isp layStatus ( conMeasurelD T MeasuresFrameIndex ) 
aMeasures • A vgAreaMan = !AVG_MANING 'Measure ttlD 

Call DisplayStatus ( "RZA Distance"! GISNonSfiLFrameIndex ) 
aMeasures . DistToRecruit = !DIST_RZA 'Measure 

Call D isp lays tatus ( conMeasurelE 1 MeasuresFrameIndex ) 
aMeasures . TotalAvailClos = !AVAIL_CLOS 'Measure 

Call D i splayStatus ( conMeasurel3 ! MeasuresFrameIndex ) 



allGasurGS • IRR = !IRR 'flGasurG **13 

Call DisplayStatus (conflGasurGlM T IlGasurG sFramG IndGX ) 
aflGasuPGS • RGcrui triarkGt = !REC_I1ARKET 'IlGasurG 

Call D i splayS tatus ( condGasurGliS T nGasurGsFramGindGX ) 
atlGasuPGS • RGassignmGnts = !REASSIGN 'flGasuPG #15 

Call DisplayStatus (”AnSA DistancG^T GISNonSflLFramGlndGX ) 
aflGasuPGS • D is tToAHS A = !DIST_AHSA 'IlGasuPG ttlb 

Call D i splayStatus ( ”ECS DistancG^i GISNonSflLFpamGindGX ) 
allGasuPG s . D i s tToECS = !DIST_ECS 'tlGasuPG **17 

Call D i splayStatus ( conNoAuthNG T GISNonSflLFramGlndG x ) 

Call D i splayStatus ( vbNul IString 1 GISNonS(3LFpamGlndGX ) 

Call D i splayStatus ( conflGasuPGl6 T NonGISFramGlndGX ) 

Call D i splayStatus ( vbNul IString n NonGISFramelndex ) 
allGasuPGs . FacUkndUsGd = !li)KND_USED 'IlGasupe **16 

Call IncPGmGntPpogpGssBar 
Call IncPGfnGntPpogpGssBap 

• FindFipst '^HOVUIC = & cHovUic & 

If Not -NoHatch ThGn 

allGasuPGs . novUIC_riatch = Tpug 

Call DisplayStatus ( conriGasuPGlT T IlGasuPGsFpamelndGX ) 
aflGasuPGS - nOSAvai IClos = !nOS_AVAIL 'tlGasuPG **1T 

Call DisplayStatus ( conllGasuPGED T IlGasuPGsFpamGlndGx ) 
afiGasuPGs • IRR_nOS = !IRR_nOS 'rieasuPG **ED 

'IncPGmGnt PpogpGss Bar to account for No Tomp TablGs creatGd 
iSta tusBarllax = iS tatusBarllax - 12 
barS(3Ls tatus . Hax = iStatusBarHax 
EIsg 

allGasuPGS • novUIC_riatch = FalsG 
End If 
End If 
• Cl OSG 
End With 

SGt PsApchi VGdFac i 1 i ty = Nothing 

End Sub 

PpivatG Sub CpGatGnOS_IntGPGstTablG (ByVal cllovUic As String) 
cProcNamG = '’CREATE_nOS_INTEREST_TABLE” 

Dim c(3dGfnS(3L As String 

Dim bNoASSNxnOS_Exists As Booloan 

Ari GsS tatusBar . PanG 1 s ( 1) . iGXt = BuildnOSIntGPGstnSG 

bNoASSNxMOS^Exists = CPGatGNoASSNxhOStablG ( cHovUic) 

If bNoASSNxhOS^Exists ThGn 

'CPGatG IntGPim TablG C HOS^INTEREST 1 

Call Disp layStatus ( Tb l_nOSIntGPGSt T SflLFramGlndGX ) 

c(3dGfnS(3L = Ge tnOSIn tGPGsttJuGpy 

Call BuildAccGssTablG (Tbl_nOSIntGPGstn (3dG f_H0SIn teres t t c(3defnS(3L) 

End If 

End Sub 

Private Function CreatGNoASSNxHOStablG (ByVal cllovUic As String) As Boolean 
Dim cfldefnSflL As String 

'Create Interim Table 1C NoASSNxHOS 1 

c(3dGfnS(3L = No ASSNxnOStJueryBegin & cllovUic & No ASSNxflOSfluGpyEnd 
Call D i splayStatus ( Tbl__NoASSNxHOS T S(3LFramG Index ) 

Call BuildAccGssTablGdbl^NoASSNxnOSi (3def_No ASSNxMOS c(3defnS(3L) 
CrGateNoASSNxnOStabl G = True 

End Function 

Private Function Gg tHOSInt gpgs tfluery ( ) As String 
cProcName = '’GET_I10S_INTEREST_(3UER Y'’ 

Dim rsnOS_Total As Recordset 
Dim rsn0S_Top3 As Recordset 



Dim iRecordCtr As Long 
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Dim inOS_Total As Integer 
Dim iH0S_Top3 As Integer 
Dim nOSPercent As Single 

nOSPercent = D-S 
inOS_Total = D 
inOS_Top3 = 0 

On Error GoTo EH_f10S i nteres t 

'Execute S(3L (3uery for f10S_Count Summation 

Set rsnOS_Total = db Acropo 1 i s • OpenRecordset ( n0S_Tota 1 fluery t dbOpenDynaset i 
dbReadOnly ) 

If (3uerySumNotNULL(rsnOS_Total !n0S_T0TAL) Then 
inOS_Total = rsnOS_Total !nOS_TOTAL 
Else 

inOS_Total = -1 
End If 



'Execute SQL (2uery for f10S_Top 3 

Set rsn0S_Top3 = dbAcropo 1 i s - OpenRecordse t ( nOS_Top3(2uery t dbOpenDynaset t 
dbReadOn 1 y ) 



'Sum Top 3 nOS's 
lilith rsnOS_Top3 

If Tabl eNotNULL ( rsf10S_Top3 ) Then -MoveLast 
iRecordCtr = -RecordCount 



If Tabl eNotNULL ( rsf10S_Top3 ) And iRecordCtr = 3 Then 
. floveFirst 

inOS_Top3 = !nOS_COUNT 



- MoveNext 

in0S_Top3 = inOS_Top3 + ! M0S_C0UNT 



. rioveLas t 
inOS_Top3 
Else 

inOS_Top3 
End If 
End Uith 



inOS_Top3 + !nOS_COUNT 
1 



'Determine flOS of Interest 

If ( CSng ( inOS_Top3 ) / CSng ( iH0S_Total ) ) > flOSPercent Then 
GetnOSIn terest(3uery = nOS_INT_Top3(2uer y 
Else 

Ge tnOSIn terestfiuery = nOS_INT_Total(2uery 
End If 



'Delete Recordset Objects 
rsf10S_Total - Close 
r s t1 0 S_T op3. Close 
Set rsf10S_Total = Nothing 
Set rsf10S_Top3 = Nothing 

Exit Function 

E H_n OSinterest: 

Select Case Err. Number 

Case ERR_InvalidUseOFNull 
inOS_Total = -1 
Resume Next 



Case Else 'Trap all other Errors & Report 
Call 0utputERR0R_L0G 
End 



End Select 
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End Function 



Private Sub ResetSfiLf rames ( ) 

lstbxStatus(neasuresFrameIndex).Clear 
txtStatus (HeasuresFramelndex ) . Text = 

lstbxStatus(NonGISFrameIndex)*Clear 
tx tSt a tus ( No nGISFramelndex ) . Tex t = "" 

lstbxStatus(GISNonS(3LFrameIndex).Clear 
txtStatus (CISNonS(3LFrameIndex ) -Text = "" 

lstbxStatus(S(3LFrameIndex)-Clear 
txtStatus (SflLFrameIndex ) . Text = 

End Sub 

Private Sub NonGISfluery ( ByRe f afleasures As fleasur es_Type ) 
cProcName = "N0N_GIS_(3UERY" 

Dim rsFacBklogdnaintrieasure As Recordset 'Measure 
Dim r sOpCos tFacCondMeasure As Recordset 'Measure ^2 & 

Dim rsFacAgeMeasure As Recordset 'Measure 

Dim rsFacOwnedUsedMeasure As Recordset 'Measure 

Set rsFacBklogdMaintMeasure = dbAcropol is • OpenRecordset(Tbl_RPINFODTT 
dbOpenTable T dbReadOnly) 

rsFacBklogdMaintMeasure . Index = "FACID" 

Set r sOpCos tFacCondMeasure = dbAcropo 1 i s • OpenRecordset ( Tbl_FPS i dbOpenTable-i 
dbReadOnly) 

rsOpCo s tFacCondMeasure . Index = "FACID" 

Set rsFacAgeMeasure = dbAcropo 1 is • OpenRecordset ( Tb l_Interest -i dbOpenTablei 
dbReadOnly) 

rsFac AgeMeasure . Index = "FACID” 

Set rs FacOwnedUsedMeasure = dbAcropo 1 is • OpenRecordset ( Tbl_Compl ex t 
dbOpenTablei dbReadOnly) 
rsFacOwnedUsedMeasure • Index = "FACID” 

'Calc Measure 

With r sFacBk 1 ogdMai ntMeasure 
•Seek aMeasures • FacID 

If Not (.NoMatch) Then 

aMeasures • FacBack logdMai nt = !Maint_Cost 
Else 

aMeasures . FacBack logdMai nt = Def aul tErrorValue 
End If 

Call DisplayStatus ( conMeasurel T NonGISFrameIndex ) 

End With 

'Calc Measure 

rsOpCos tFacCondMeasure • Seek aMeasures . FacID 

If Not ( rsOpCostFacCondMeasure -NoMatch) Then 

aMeasures - OperatingCost = rsOpCos tFacCondMeasure ! C0ST_PR_SF 

'Verify that the stored value is not NULL 
If Not IsNul 1 ( rsOpCostFacCondMeasure ! FAC_C0ND ) Then 
aMeasures • FacCond = rsOpCos tFacCondMeasure ! FAC_C0ND 
Else 

aMeasures - FacCond = Def aul tErr orVa lue 
End If 
Else 

aMeasures - Operati ngCost = Def aul tErrorValue 
aMeasures - FacCond = Def aul tErrorValue 
End If 

Call D isplayStatus ( conMeasureBn NonGISFrameIndex ) 

Call D i sp layStatus ( conMeasureM T NonGISFrameIndex ) 
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'Calc NeasurG 

With rsFacAgeneasurG 

• Seek " = atlGasurGS . FacID 
If Not (.Nollatch) Then 

If Not IsNull ( !DATE_AC(3) Then 

aneasuPGS • FacAge = Compu tGFaci 1 i tyAge ( ! DATE_AC(3 ) 

EIsg 

aflGasuPGS ■ FacAgG = Dg f au 1 tErrorValue 
End If 
EIsg 

aNGasuPGS • FacAgG = DGf aul tEppopValuG 
End If 

Call DisplayStatus (conflGasupGB T NonGISFpamGindex ) 

End With 

'Calc riGasuPG ifl 

psFacOwnGdUsGdtlGasupG . SGGk " = aflGasupes . FacID 

If Not (psFacOwnGdUsGdflGasuPG • NoHatch) Then 

If Not IsNul 1 (psFacOwnGdUsGdriGasuPG ! FAC_Oli)NED) ThGn 

afleasuPG s • FacOwned = PsFacOwnGdUsGdriGasupG ! FAC__0UNED 
EIsg 

afiGasuPGS . FacOwnGd = DGf au 1 tEppopValuG 
End If 

ariGasupGS . FacUkndUsGd = PsFacOwnGdUsGdtlGasuPG ! FAC_UKND_USED 

EIsg 

aflGasuPGS . FacOwnGd = DgF aul tEppopValuG 
aflGasuPGS • FacUkndUsGd = DGf aul tEppopValuG 
End If 

Call D i splayS ta tus ( conHcasupeS 1 NonGISFpamGindex ) 

Call D i splayS ta tus (conflGasuPGlfl 1 NonGISFpamGindGX ) 

Call DisplayStatus (vbNul IStpingi NonGISFpamGindGx ) 

'CIOSG RGCOPdSGt ObjGCtS 

SGt PsFacBk 1 ogdriaintriGasuPG = Nothing 
SGt psOpCos tFacCondflGasuPG = Nothing 
SGt psFac AgGtlGasuPG = Nothing 
SGt PsFacOwnGdUsGdriGasupG = Nothing 
End Sub 

PpivatG Sub GISfluGPy (ByRG f aflGasupes As nGasupes_TypG ) 
cPpocNamG = "GIS_(3UERY" 

Dim cfldGfnS(3L As Stping 
Dim PsApchivG As RGCopdsGt 
Dim PsNoREflD As RGCoPdSGt 
Dim PsNoAuthNG As RGCOPdsGt 
Dim psNoASSN As RGCOPdsGt 
Dim PsNoLOSS As RGCOPdsGt 
Dim psNoXFER As RGCOPdsGt 
Dim PsDpillTotal As RGcopdsGt 
Dim psDpillSAT As RecopdsGt 
Dim PsAvailClos As RGCopdsGt 
Dim PsIRR As RGCopdsGt 
Dim PsRGCPui triapkGt As RGcopdSGt 
Dim psRGass i gnmGnts As RGcoPdSGt 
Dim PsnOSAvailClos As RGcoPdSGt 
Dim psIRR_nOS As RGCOPdsGt 

'Display Statusbap mGSsagG 

Ap i GsS tatusBap • PanG Is ( 1) . iGxt = S(3LS tatusflSG a aflGasuPGS - FacID 

' If Not atlGasuPGS . Apchi vGd ThGn 

'ExGcutG Haplnfo GGO(3uGpy via OLE intGPfacG 

Call DisplayStatus (ariGasuPGS -FacIDi Hapi nf oFpamGindGx ) 

If btlapfluGPyAct i VG ThGn 

Call napInfotSuGPyCaflGasuPGS.FacID) 

EIsg 

Call DisplayliGssagG (OLEf ailGdnSG-i vbCpiticali vbOKOnlyi 
conOLEcaption ) 
bflapBas i cRunn ing = FalsG 
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Call cmdEx i tBtn_Cl i ck 
End If 

Call ElapsedTimer (Time$ ( ) ) 

^Get calculated AUSAt ECS-i 8 RZA Distances from proposed Facility 
Call GetFaci li tyDistances (atleasures) 'Measure Itn 17 

'Build Temp Tables FinanceCY-i AreaFacIDi AreaZipCodei AreaUICi AreaClosUIC 

Call CreateFinanceTempTable 

Call Create AreaFacIDTempTabl e 

Call CreateAreaUICTempTable 

Call CreateAreaClosUICTempTable 

Call CreateAreaZipCodeTempTable 

Call CreateAreaGlflZipTempTable 

Call CreateAreaGlfinOSTempTable 

Call D isplayStatus ( vbNul IStr ing T S(3LFrameIndex ) 

'Calculate Measure ♦♦b 

Call Di splayStatus ( conMeasuretn MeasuresFrameIndex ) 

Set rsNoAuthNG = dbAcropolis . OpenRecordset (ExTbl_AreaDistanceT 
dbOpenSnapshot T dbReadOnly) 
rsNoAuthNG-MoveFirst 

Call Di splayStatus ( conNoAuthNG T GISNonS(3LFrameIndex ) 

Call Di splayStatus ( vbNul IString T GISNonSflLFrameIndex ) 

Set rsNoREflD = dbAcropo 1 i s • OpenRecordse t ( NoReqd(3uery t dbOpenSnapsho t t 
dbReadOnly) 

If (3uerySumNotNULL(rsNoRE(3D!TOTAL_RE(3D) Then 

aMeasures • Competi tion = r sNo AuthNG ! N 0_AUTH_NG + rsNoREGD ! TOT AL_RE(3D 
Else 

aMeasures • Competi tion = Def aul tErrorValue 
End If 

'Calculate Measure #7 

Call Di sp lays tatus ( conMeasure7 T MeasuresFrameIndex ) 

Set rsDrillTotal = dbAcropol is . OpenRecordset (Dri 1 ITotaltJueryi 
dbOpenSnapshot T dbReadOnly) 

Call ElapsedTimer (Time$ ( ) ) 

Set rsDrillSAT = dbAcropo 1 is • OpenRecordset ( Dr i 1 lSAT(3uery t dbOpenSnapshot t 
dbReadOnly ) 

If fluerySumNotNULLCrsDrillTotal !DRILL_TOTAL) And 
fluerySumNotNULL (rsDrillSAT! TOT AL_S AT) Then 
If rsDr i 1 ITo tal ! DRILL_T0T AL Then 

aMeasures ■ AreaDri 1 1 Attend = rsDr i 1 1 SAT ! T0TAL_S AT / 
rsDrillTotal ! DRILL„TOTAL 
Else 

aMeasure s • AreaDri 1 1 Attend = Def aultErrorValue 
End If 
Else 

aMeasures • A reaDri 1 1 Attend = Def aul tErrorValue 
End If 

'Calculate Measure 

Call DisplayStatus ( conMeasurefi T MeasuresFrameIndex ) 

Set rsNoASSN = dbAcropol i s . OpenRecordset ( NoASSNfluery t dbOpenSnapsho t t 
dbReadOnly ) 

Call ElapsedTimer (Time^ ( ) ) 

Set rsNoLOSS = dbAcropol i s • OpenRecordset ( NoLOSSfluery i dbOpenSnapsho t t 
dbReadOnly) 

If (3uerySumNotNULL(rsNoASSN!T0TAL_ASSN) Then 

If CuerySumNotNULL(rsNoLOSS!TOTAL_LOSS) And rsNoASSN ! TOTAL^ASSN Then 
aMeasures • AreaLossRate = rsNoLOSS I T0TAL_L0SS / rsNoASSN ! TOTAL_ASSN 
Else 

aMeasures • AreaLossRate = □ 

End If 
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DefaultErrorValue 



Else 

a(lGasur 0 s • AreaLossRate = 

End If 

'Calculate rieasure 
Call Di splayStatus ( conrieasureT T neasuresFramelndex ) 

Set rsNoXFER = dbAcropo 1 i s • OpenRecordset ( NoXFER(3uery i dbOpenSnapsho 1 1 
dbReadOnly ) 

If (3uerySumNotNULL(rsNoASSN!T0TAL_ASSN) Then 

If (3uerySumNotNULL(rsNoXFER!T0TAL_XFER) And rsNoASSN ! TOT AL_ASSN Then 
aMeasures.AreaXferRate = rsNoXFER ! TOTAL_XFER / rsNo ASSN ! TOT AL_ASSN 
Else 

aheasures . AreaXf erRate = □ 

End If 
Else 

aheasures • AreaXf erRate = Def aul tErrorValue 
End If 

'Calculate Measure #1D 

Call Di splayS tatus ( conMeasurelD T MeasuresFramelndex ) 

If (3uerySumNotNULL(rsNoASSN! TOTAL_ASSN) And 
(3uerySumNotNULL(rsNoRE(3D!TOT AL_RE(3D ) Then 

afleasures • A vgAreaMan = rsNo ASSN ! TOT AL_ASSN / rsNoRECD ! T0TAL_RE(3D 
Else 

aMeasures . A vgAreaMan = D 
End If 

'Calculate Measure #1E 

Call DisplayStatus ( conMeasurelEi MeasuresFrameIndex ) 

Set rsAvailClos = dbAcropol i s • OpenRecordset ( Total Aval lClos(3uery t 
dbOpenSnapsho 1 1 dbReadOnly) 

If (3uerySumNotNULL(rsAvailClos!T0TAL_AVAlL) Then 

aMeasures . TotalAvai IClos = rsAvailClos ! TOTAL_AVAIL 
Else 

aMeasures . Total Aval IClos = De f aul tErrorVal ue 
End If 

'Calculate Measure 

Call DisplayStatus ( conMeasurel3 T MeasuresFrameIndex ) 

Set rsIRR = dbAcropol i s - OpenRecordset ( Total IRR(3uery i dbOpenSnapsho t ■» 
dbReadOnly ) 

If (3ueryCoun tNotNULL ( rsIRR ! T0TAL_IRR ) Then 
aMeasures • IRR = rsIRR ! T0TAL_IRR 
Else 

aMeasures . IRR = Def aul tErrorValue 
End If 

'Calculate Measure 

Call Di sp layStatus ( conMeasurelM *1 MeasuresFrame Index ) 

Set rsRecru i tMarket = dbAcropol i s . OpenRecordse t ( Recrui tMarket(3uery i 
dbOpenSnapsho t T dbReadOnly) 

If (3uerySumNotNULL ( rsRecrui tMarket * TOTAL_MARKET ) Then 

aMeasures - Recrui tMarket = rsRecrui tMarket ! TOTAL_MARKET 
Else 

aMeasures • Recrui tMarket = Def aul tErrorValue 
End If 

'Calculate Measure ttlS 

Call Di splayStatus ( conMeasurelSi MeasuresFrameIndex ) 
c(3defnS(3L = Reassign(3ueryBegin & cMovUic-UIC & Reass ignfiueryEnd 
Set rsReas s i gnments = dbAcropo 1 i s • OpenRecordset ( c(3def nS(3L n 
dbOpenSnapshot 1 dbReadOnly) 

If (3uerySumNotNULL ( rsReassi gnments ! TOTAL_RESERVISTS ) Then 

aMeasures • Reass i gnments = rsReass i gnments ! TOT AL_RESERVISTS 



Else 

afleasures . Reassignments = Def aul tErrorValue 
End If 

'Calculate fleasure 

Call Di splayStatus ( confleasureni HeasuresFramelndex ) 

Set rsflOSA vai IClos = dbAcropol is • OpenRecordse t ( To ta 1 Cl o sl10S(3uery i 
dbOpenSnapsho t 1 dbReadOnly) 

If (3uerySumNotNLILL (rsflOSAvai IClos ! T0TAL_CL0S_n0S) Then 
afleasures • nOSAvai IClos = rsflOSAvai IClos ! T0TAL_CL0S_M0S 
Else 

afleasures • noSAvai ICl os = Def aul tErrorValue 
End If 

'Calculate fleasure 

Call DisplayStatus (confleasureEOi fleasuresFrameIndex ) 

Set rsIRR_f10S = dbAcropolis • OpenRecordset (TotalIRR_f10Si3ueryT 
dbOpenSnapshot 1 dbReadOnly) 

If (2ueryCoun tNo tNULL ( rsIRR_f10S TOTAL_IRR_nOS ) Then 
af1easures.IRR_f10S = rsIRR_f10S ! TOT AL_IRR_f10S 
Else 

afleasures • IRR_f10S = Def aul tErrorValue 
End If 

Call ElapsedTimer (Time$ ( ) ) 

Elself Not afleasures . f1ovUIC_f1atch Then 

'Execute flapinfo Geo(3uery via OLE interface 
Call DisplayStatus (afleasures . FacID 1 flapi nf oFrameIndex ) 

If bf1ap(3ueryActi ve Then 

Call f1apInfo(3uery(af1easures-FacID) 

Else 

Call Displayflessage ( OLEf ai ledflSGi vbCritical-i vbOKOnlyi conOLEcap t i on ) 
bflapBasicRunning = False 
Call cmdExi tBtn_Click 
End If 

Call ElapsedTimer (Tirne^ ( ) ) 

'Build Temp Tables FinanceCYi AreaFacID-i AreaZipCodei AreaUICi AreaClosUIC 
Call CreateAreaFacIDTempTable 
Call CreateAreaUICTempTable 
Call CreateAreaClosUICTempTable 
Call CreateAreaZipCodeTempTable 
Call CreateAreaGlflflOSTempTable 

Call D i sp 1 ayS tatus ( vbNu 1 IStri ng 1 S(3LFrameInde x ) 
i S tatusBarflax = i StatusBarflax - M 
barS(3Ls tatus • flax = i StatusBarflax 

'Calculate fleasure 

Call D i sp layStatus ( confleasurelT 1 fleasuresFrameIndex ) 

Set rsflOSA vai IClos = dbAcropolis . 0penRecordset(TotalClosf10S(3ueryi 
dbOpenSnapsho t 1 dbReadOnly) 

If (2uerySumNotNULL(rsf10SAvailClos!T0TAL_CL0S_f10S) Then 

afleasures . nos A vai IClos = rsHOSAvai IClos ! TOTAL_CLOS_nOS 
Else 

aheasures • nos A vai ICl os = De f aul tErrorValue 
End If 

'Calculate neasure ♦♦EO 

Call DisplayStatus (conneasureED T neasuresFrameIndex ) 

Set rsIRR_n0S = dbAcropol i s . OpenRecordse t ( To ta lIRR_n0S(3uery -i 
dbOpenSnapsho t T dbReadOnly) 

If (2ueryCountNotNULL(rsIRR_n0S!T0TAL_IRR_n0S) Then 
aneasures.IRR_n0S = rsIRR_noS ! TOT AL_IRR_n0S 
Else 

aneasures • IRR_n0S = Def aul tErrorVa lue 
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» End If 

' Call ElapsedTimer (Time$ ( ) ) 

» End If 

'Delete Recordset Objects 
Set rsNoAuthNG = Nothing 
Set rsNoREc3D = Nothing 
Set rsNoASSN = Nothing 
Set rsNoXFER = Nothing 
Set rsNoLOSS = Nothing 
Set rsDrillTotal = Nothing 
Set rsDrillSAT = Nothing 
Set rsAvailClos = Nothing 
Set rsRecrui tflarket = Nothing 
Set rsReass i gnments = Nothing 
Set rsnOSA vai 1 Cl os = Nothing 
Set rsIRR_hOS = Nothing 
Set rsIRR = Nothing 
End Sub 

Private Sub C 1 oseGISCuery ( ) 

cProcName = ”CL0SE_GIS_(3UER Y" 

objGeo(3uery.RunhenuCommand h_FILE_EXIT 

Call D i sp 1 ayStatus ( Comp 1 etehSG T tleasuresFramelndex ) 

Call DisplayStatusCCompletehSG 1 NonGISFrameIndex ) 

Call DisplayStatus ( vbNul IString T Mapinf oFrameIndex ) 

Call Di splayStatus (CompletenSGi tlapinf oFrameIndex ) 

Call DisplayStatus (CompletenSGi GISNonScJLFrameIndex ) 

Call DisplayStatus (CompletenSGi St3LFrameIndex ) 

' barSflLstatus • Value = i S tatusBarflax 

End Sub 

Private Sub GetFaci 1 i tyDistances (ByRef atleasures As fleasure s_Type ) 
cProcName = "GET_FACILITY_DIST ANCES” 

Dim r sFac i 1 i tyDis tancelleasures As Recordset 'Heasures ♦♦Ibi ttl7 

On Error GoTo EH_FacDist 

'Open External Table 

Set rsFaci 1 i tyDistancefleasures = 

dbAcropolis* OpenRecordset ( ExTbl_AreaD i stance t dbOpenDynasett dbReadOnly) 

Call Di splayStatus ("AfISA Distance"! GISNonSflLFrameIndex ) 

Call D i sp 1 ayStatus ( "ECS Distance"! GISNonSfiLFrameIndex ) 

Call Di splayStatus ("R2A Distance"! GISNonSflLFrameIndex ) 

If Tabl eNo tNULL ( rsFac i 1 i tyD i s tanceheasures ) Then 
Uith rsFaci 1 i tyDistancetleasures 
. HoveFirst 

'Input Facility Distances into fleasure Table 

afleasures • Di stToAfIS A = !Af1SA_DIST 'fleasure 
afleasures • D istToECS = !ECS_DIST 'fleasure ^17 

afleasures • D i stToRecru i t = !RZA_DIST 'fleasure ^11 
End Uith 
Else 

afleasures • D i stToAflS A = Def aul tErrorVa 1 ue 
afleasures • Di stToECS = Def aul tErrorVal ue 
afleasures • D i stToRecrui t = Def aul tErrorVal ue 
End If 

Call Di splayStatus (vbNul IString ! GISNonS(3LFrameIndex ) 

'Delete Recordset Object 
rsFacilityDistancefleasures-Close 
Set rsFaci 1 i tyDi stancefleasures = Nothing 
Exit Sub 
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EH_FacDist: 'Error Handler 



Select Case Err. Number 

Case ERR_Ex trnTabl eNot Attached 

'call AttachEx ternalTable ( ExTbl_AreaDistance ) 

Resume 

Case Else 'Trap all other Errors & Report 
Call 0utputERR0R_L0G 
Resume Next 
End Select 
End Sub 

Private Sub CreateFinanceTempTable ( ) 

cProcName = "CRE ATE_FINANCE_TEnP_TABLES" 

Dim c(2defnS(2L As String 

Dim dtDate As Date 

Dim cCY_(3TR As String * 1 

'Initialize Date parameters 
dtDate = Now 

cCY_(3TR = DatePart ( T dtDate) 

Select Case CInt ( cCY_(2TR ) 

Case M 

c(3defnS(2L = (21FY_SCRN 
Case 1 

c(3defnS(3L = (2EFY_SCRN 
Case E 

c(2defnS(3L = (33FY_SCRN 
Case 3 

c(2defnS(3L = (3MFY_SCRN 
End Select 

'Create Interim Table C FINANCE_CY 1 

c(3dGfnS(3L = CY_Fi nance(2uery S; c(3defnS(2L 

Call Di spl ayStatus ( Tbl_FinanceCY T SCLFramelndex ) 

Call BuildAccessTable (Tbl_FinanceCYT (3def_FinanceCY t c(2defnS(2L) 

End Sub 

Private Sub CreateAreaFacIDTempTable ( ) 

cProcName = "CREATE_AREA_FACID_TEnP_TABLE” 

Dim c(3defnS(3L As String 

'Create Interim Table C AREA_FACID 3 

c(2defnS(2L = AreaFacIDConverttJuery 

Call DisplayStatus (Tbl_AreaFacIDsT S(3LFrameIndex ) 

Call BuildAccessTable (Tbl_ArGaFacIDsi (3dGf_AreaFacIDsT c(3defnS(2L) 
End Sub 

Private Sub CreateAreaUICTempTab 1 e ( ) 

cProcName = "CRE ATE_AREA_UIC_TEnP_TABLE" 

Dim c(3defnS(3L As String 

'Create Interim Table IL AREA_UIC 1 
c(3defnS(3L = AreaUICtSuery 

Call DisplayStatus (Tbl^AreaUICsi S(3LFramGlndex ) 

Call Bui IdAccessTabl G ( Tbl_ArGaUICs T (3dGf_ArGaUICs t c(2defnS(3L) 

End Sub 

Private Sub CreateAr eaC 1 osUICTempTab 1 e ( ) 
cProcName = "CREATE_AREA_UIC_TEMP_TABLE" 

Dim c(2defnS(3L As String 

'Create Interim Table IL AREA_CL 0S_UIC 3 
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c(2defnS(2L = AreaClosUIC(2uery 

Call DisplayStatus (Tbl_AreaClosUICs 1 S(2LFrameIndex ) 

Call Bui IdAccessTable ( Tbl_AreaClosUICs T (2de f_AreaC losUICs i c(2defnS(2L) 

End Sub 

Private Sub CreateAreaZipCodeTempTable ( ) 
cProcName = "CREATE_ARE A_UIC_TEnP_TABLE" 

Dim c(3defnS(2L As String 

'Create Interim Table C AREA_ZIPCODE 3 

c(2defnS(3L = AreaZipCodeConvert(2uery 

Call Di splayStatus ( Tbl_AreaZi pCodes T S(2LFrameIndex ) 

Call Bui IdAccessTable ( Tbl_AreaZipCodes n (2def_AreaZ ipCodes t c(3defnS(3L) 

End Sub 

Private Sub Create AreaGlflZipTempTable ( ) 
cProcName = "CRE ATE_AREA_UIC_TEnP_T ABLE" 

Dim c(3defnS(3L As String 

'Create Interim Table C AREA_Glfi_ZIP 1 
c(2defnS(2L = AreaGiaUICZip(2uery 

Call DisplayStatus (Tbl_AreaGiaUICZips T S(2LFrameIndex ) 

Call Bui IdAccessTable ( Tbl_AreaGlfiUICZ ips T (3def_AreaGlfiUICZips n c(3defnS(2L) 

End Sub 

Private Sub Create AreaGlfiMOSTempTab 1 e ( ) 
cProcName = "CREATE_AREA_UIC_TEnP_TABLE" 

Dim c(3defnS(2L As String 

'Create Interim Table E AREA_Gia_nOS 1 
c(3defnS(3L = AreaGli8UICZipnOS(2uery 

Call Di splayStatus ( Tb l_AreaGiaUICZi pMOS 1 S(2LFr ameindex ) 

Call BuildAccessTable(Tbl_AreaGlflUICZipMOS-. (3def_AreaGlflUICZipn0S ci2defnS(3L) 
Call ElapsedTimer (Time$ ( ) ) 

End Sub 

Private Sub De leteTempAccessTables ( ) 

cProcName = "DELETE_TEMP_ACCESS_TABLES" 

Call DeleteAccessTableC Tbl_nOSInteres t ) 

Call DeleteAccessTable ( Tbl_No ASSNxflOS ) 

Call DeleteAccessTable ( Tbl_Fi nanceCY ) 

Call DeleteAccessTable (Tbl_AreaClosUICs) 

Call DeleteAccessTable ( Tb l_AreaFacIDs ) 

Call DeleteAccessTable ( Tbl_AreaUICs ) 

Call DeleteAccessTable (Tbl_AreaZipCodes) 

Call DeleteAccessTable ( Tbl_AreaG16UICZips ) 

Call DeleteAccessTable ( Tbl_AreaGiaUICZipnOS ) 

End Sub 

Private Sub OutputComputedHeasures (ByRef afleasuresC) As Measure s_Type i _ 

ByVal iFacIndex As Byte) 

cProcName = "OUTPUT_COnPUTED_MEASURES" 

Dim i As Byte 

'Output Computed Measures 
With Ari esStatusBar 

• Pane 1 s ( 1) . Text = OutputMeasuresMSG 

Call OutputMeasuresGrid (aMeasures ( ) T iFacIndex) 

Call Output AriesMeasuresExce 1 ( aMeasures () 1 iFacIndex) 

DoE vents 

For i = □ To iFacIndex 

Call OutputAriesFacilityInfo(aMeasures(i) ) 

Next i 

• Pane Is ( 1 ) • Tex t = LDULaunchMSG 
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tabAr iesHap . Tab = E 
f raLDUcntrl • Vis ibl G = True 
End Uith 
Refresh 
End Sub 



Private Sub OutputAriesFacil ityinf o (ByRef afleasures As neasures_Type ) 
cProcName = "OUTPUT_ARIES_nEASURES_TABLE" 

Dim i As Byte 'Loop Variable 

Dim rsArchi vedFaci 1 ity As Recordset 
Dim (3defnS(3L As String 

(3defnS(3L = Archi vedFaci 1 i tyCueryBegin 8. aPleasures • FacID & 
ArchivedFacility(3uGryEnd 

Ar iesStatusBar . Panels ( 1) • Text = OutputArchi vetlSG 
Refresh 



'Open Facility Respository Database 

Set rsArchi vedFaci 1 ity = dbTel i ko . OpenRecordset ( Tbl_Ar i es Ar ch i ve t 
dbOpenDynaset ) 

If Not aHeasures . Archi ved Then 

Call Ar chi veFac i 1 i tytleasures ( rsArchi vedFaci 1 i ty T aMeasures) 

Elself Not atleasur Gs • flovUIC^riatch Then 



Call ArchiveFacil ityHeasures (rsArchivedFacilityi arieasures) 
End If 

'Delete Database Objects 
Set rsArchi vedFacil ity = Nothing 
End Sub 



Private Sub Archi veFac i 1 i tyUeasures ( ByRef afleasures As 



With rsfleasures 
• AddN ew 

'Transfer fleasures to Proposed Facility 
!Fac_ID = afleasures . FacID 
!FAC__f1AINT = afleasures - FacBack 1 ogdflaint 
!FAC_0PC0ST = afleasures . OperatingCost 
!FAC_AGE = afleasures . FacAge 
!FAC_C0ND = afleasures • FacCond 
!FAC_0WNED = afleasures - FacOwned 
ICOnPETION = afleasures . Competition 
!DRILL_ATND = afleasures - AreaDri 1 1 Attend 
!AREA_L0SS = afleasures . AreaLossRate 
!AREA_XFER = afleasures • AreaXferRate 
!AVG_f1ANING = afleasur es - A vg Areaflan 
!DIST_RZA = afleasures • D is tToRecrui t 
!AVAIL_CLOS = afleasur es . Total Avai ICl os 
!IRR = afleasures • IRR 

!REC_f1ARKET = afleasur es • R ecru i tflarket 
!REASSIGN = afleasures -Reassignments 
!DIST_Af1SA = afleasures . DistToAflS A 
!DIST_ECS = afleasures -DistToECS 
!lilKND_USED = afleasures • FacUkndUsed 
inOS_AVAIL = aneasures.nOSAvailClos 
!IRR_f10S = afleasures . IRR_f10S 
inovUIC = cflovUic.UIC 



Record 
' fleasur G 
' fleasur G 
' fleasur G 
' fleasure 
' fleasure 
' fleasure 
' fleasure 
' fleasure 
' fleasure 
' fleasure 
' fleasure 
'fleasure 
' Measure 
' Measure 
' Measure 
' Measure 
' Measure 
'Measure 
'Measure 
' Measure 
' Measure 



Measures_Type) 



#3 

#5 

♦HE 

«13 

#15 

#lb 

#17 

#lfl 

#n 

#E0 



'Save Changes to Database 
- Update 
End With 
End Sub 



Private Sub OutputMeasur esGr id ( ByRef aMeasuresC) As MeasurGS_Type i ByVal Index 
As Byte) 

cProcName = ”OUTPUT_MEASURES_GRID" 

Dim i As Long 
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Call Ini tneasuresGrid ( Index ) 

With gridHeasures 

For i = 0 To Index 
-Col = i + 1 
-Row = D 

-Text = afleasures ( i ) - FacID 
•Row = 1 

-Text = aDeasures ( i ) - FacBack 1 ogdflaint 
-Row = B 

-Text = afleasures ( i ) • Operat ingCost 

• Row = 3 

-Text = aDeasures ( i ) - FacAge 
-Row = M 

-Text = afleasures ( i ) • FacCond 
-Row = 5 

• Text = afleasures ( i ) - FacOwned 
•Row = b 

• Text = afleasures ( i ) . Compet i t i on 
•Row = 7 

• Text = aNeasures ( i )- AreaDri 1 1 Attend 
•Row = 6 

• Text = afleasures ( i ) . AreaLossRate 
•Row = T 

• Text = arieasures ( i ) . AreaXf erRate 
•Row = ID 

• Text = arieasures ( i ). A vgAreaDan 
•Row = 11 

• Text = arieasures ( i )• DistToRecruit 
•Row = 12 

• Text = afleasures ( i ). Total A vai IClos 
•Row = 13 

• Text = alleasures ( i ) . IRR 
•Row = m 

• Text = alleasures ( i )• Recrui triarket 
•Row = 15 

• Text = alleasures ( i )• Reass i gnments 
•Row = lb 

• Text = afleasures ( i )• DistToAnSA 
•Row = 17 

• Text = afleasures ( i )• DistToECS 
•Row = Ifi 

• Text = afleasures ( i )• FacUkndUsed 
•Row = n 

• Text = afleasures ( i )• flOSAvai IClos 
•Row = 20 

• Text = afleasures ( i )• IRR_nOS 
Next i 

End With 
End Sub 

Private Sub EnableLDWbuttons ( ) 

cProcName = ”EN ABLE_LDU_BUTTONS” 

tbararies . Buttons ("matrix" )• Enabled = True 
tbarar i es . Buttons ( "hierarchy" ) . Enab led = True 
tbarar i es . Bu ttons ( "dynami c" ) • Enabl ed = True 
tbararies • Buttons ("stacked" )• Enabled = True 
End Sub 

Private Sub Compact AriesDataBase ( ) 

cProcName = "C0f1PACT_ARIES_DATABASE" 

'Compact the Acropolis Database 
Set dbAcropolis = Nothing 

DBEngine • CompactDatabase App.Path a FILE_Acropo 1 i s t App-Path & FILE_Akron 



Kill App.Path Z FILE_Acropol isBackup 
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Name App.Path & FILE_Acropol is As App.Path & FILE_Acropo 1 i sBackup 
Name App.Path & FILE_Akron As App.Path a FILE_Acropo 1 is 

'Compact the Repository Database 
Set dbTeliko = Nothing 

DBEngine. CompactDatabase App.Path a FILE_Telikoi App.Path a FILE_Titan 
Kill App.Path a FILE_Te 1 ikoBackup 

Name App.Path a FILE_Teliko As App.Path a FILE_Tel ikoBackup 
Name App.Path a FILE_Titan As App.Path a FILE_Teliko 

Call Displaytlessage (DatabaseCompactednSG *1 vbinf ormati on -i vbOKOnlyi 
conFi leCaption ) 

End Sub 
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Module 3. ARIES PUBLIC DECLARATIONS 



Purpose: Initializes all public variables and constants; Contains the variables that represent 

the SQL business rules for calculating the ARU-DM decision parameters. 

Source Type: Visual Basic for Applications 

Source File: libDECLARATIONS.BAS 

Code Listing: 



Attribute VB_Name = ”1 ibDECLARATIONS” 
Option Explicit 



Aries Status Bar Messages 



Public Const MovUICs tatbarMSG = "Enter Moving Unit's (UIC)" 

Public Const MovUIClengthMSG = "Moving UIC must be six " _ 

& "Alpha-Numeric characters" 

Public Const Fac i 1 i tyStatbarMSG = "Enter Facility Identifier " _ 

& "for Proposed Facility " 

Public Const FacID lengthMSG = "Proposed Facility Identifier " _ 

& "must be entered in I } Format" 

Public Const LaunchAriesMSG = "Select ARIES button to start " _ 

& "Facility Compari s ions" 

Public Const S(3LSta tusMSG = "Calculating Measures for Facility : " 

Public Const ClearButtonMSG = "Clears all User Entries" 

Public Const Ex i tButtonMSG = "Ends Program" 



S(3L Status Display Messages 



Public Const ArchivedFacilityMSG = "Checking ARIES Respository for " _ 

& "Facilities ..." 

Public Const Bui IdMOSInterestMSG = "Creating MOS of Interest Tables--." 
Public Const LaunchMap inf oMSG = "Loading Mapinfo and USARC Databases" 
Public Const LDULaunchMSG = "Ready to Launch LDli) Z Import " _ 

& "Measures Table--*" 

Public Const Output ArchiveMSG = "Transf erring Measures Table to " _ 

& "Aries Archive-.-" 

Public Const OutputMeasuresMSG = "Transf erring Measures Table to " _ 

& "EXCEL. - ." 

Public Const Loadi ng Archi veMSG = "Retrieving Proposed Facility : " 



' Message Box User Messages 

Public Const APIfailedMSG = "Uin3E API Connection FAILED-" _ 

S. vbCr Z vbCr Z "Unable to Complete Operation." 

Public Const Ar iesConf irmMSG = "Conduct Data Analysis Compar i s i ons" 
& " of Proposed Facilities :" 

Public Const DatabaseCompactedMSG = "ARIES Databases have been " _ 
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Compacted Successfully 



Public Const Dupl icateFaci 1 i tyflSG = "Unable to Conduct " _ 

& "Analysis." & vbCr & vbCr a "DUPLICATE FACILITY PROPOSED" 

Public Const FacIDinval idtlSG = "> is currently not on file in " _ 
a "the COnnAND PLAN or USARC GEOREF File" 

Public Const Inval idGIS(3uerynSG = "Unable to Conduct Analysisi " _ 
a vbCr a vbCr a "Insufficient Amount of FACILITY(s) PROPOSED" 

Public Const LDlilresetnSG = "Do you wish to RESET the LDU App 1 icat ionf " 
a vbCr a vbCr a "All Unsaved Data Changes will be Deleted." 

Public Const NovUIC inval idflSG = "} is currently not on file in " _ 
a "the COMMAND PLAN or USARC GEOREF File" 



Public Const NoFaci 1 i tyComparedMSG = "ARIES Facility Comparision " 
a "Operation has not been Performed-" 

Public Const OLEfailedMSG = "OLE Connection FAILED." _ 
a vbCr a vbCr a "Please RESTART Application." 



Public 


Const 


Public 


Const 


Public 


Const 


Public 


Const 


Publ ic 


Const 


Public 


Const 


Public 


Const 


Public 


Const 


Public 


Const 


Publ ic 


Const 


Public 


Const 


Publ ic 


Const 


Public 


Const 


Public 


Const 


Public 


Const 


Public 


Const 



CompleteMSG = COMPLETE 

AreaGlfiMSG = "Area Glfi" 

ArealRRMSG = "Area IRR" 

AreaflMAMSG = "Area l3MA" 
conNoAuthNG = "N0_AUTH_NG" 

CompactDatabaseMSG = "Do you wish to COMPACT the Aries Databasesf'' 
LDbJact i veMSG = "LDU Application currently not Activated." 

Pri nterReadyMSG = "Ensure Printer is Ready...." 

Progressindi catorMaxMSG = "Progress Bar Maximum Limit Exceeded" 



conFaci 1 i tyErrorCap t ion = "Proposed Facility Selection' 
conUICcapt ion = "Unit Identification Code Selection" 
conErrorCaption = "UNEXPECTED ERROR Trap" 
conOLEcaption = "Windows T5 OLE Link Error" 
conAPIcaption = "Logical Decisions-lilinBE API Link" 
conSflLcapt ion = "SOL fluery Computation" 
conFi 1 eCapt ion = "ARIES File Maintenance Operations" 



SflL fluery Definitions (Temporary Tables) 



Public Const No ASSNxM0Sl3ueryBegin = "Select MOS-i CountC*) as " _ 

& "M0S_C0UNT Into NoASSNxMOS From GlSNatl Where UIC = »" 

Public Const No ASSNxMOSflueryEnd = Group by MOS Order by " _ 

& "Counter) DESC" 

Public Const M0S_To tal(3uery = "Select Sum ( M0S_C0UNT ) as " _ 

& "M0S_T0TAL From NoASSNxMOS" 

Public Const M0S_Top3(3uery = "Select Top 3 M0S_C0UNT From " _ 

& "NoASSNxMOS" 

Public Const M0S_INT_To tal (Juery = "Select MOS Into " _ 
a "MOS_INTEREST From NoASSNxMOS Order by MOS" 

Public Const M0S_INT_Top3(3uery = "Select Top 3 MOS Into " _ 
a "MOS_INTEREST From NoASSNXMOS Order By MOS" 

Public Const CY_Fi nancefiuery = "Select UlCn Count(UIC) as UIC_T0TAL " 
a "into FINANCE_CY From FINANCE_(3TR Where " 

Public Const l31iFY_SCRN = "(UTAlfllPF + UTAEfllPF + UTA3(31PF + " _ 
a "UTAMfllPF) > ED Group by UIC Order by UIC" 

Public Const (3EFY_SCRN = "(UTAE(31PF + UTA3(31PF + UTAM(31PF + " _ 
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& ”UTA1(3CFY) > ED Group by UIC Order by UIC 



Public Const (33FY_SCRN = "(UTA3(31PF + UTAMfllPF + UTAltJCFY + " _ 

& ”UTAE(3CFY) > ED Group by UIC Order by UIC” 

Public Const (3MFY_SCRN = ”(UTAMi31PF + UTA1(3CFY + UTAE(3CFY + ” _ 

& ”UTA3(3CFY) > ED Group by UIC Order by UIC" 

Public Const AreaFacIDCon vertt3uery = "Select FAC_ID Into " _ 

8; "AREA_FACID From AreaFacIO Order by FAC_ID" 

Public Const AreaZ ipCodeConvert(3uery = "Select Zip Into " _ 

& "ARE A_ZIPC0DE From AreaZipCode Order by Zip" 

Public Const AreaUIC(3uery = "Select Distinct UIC Into AREA_UIC " _ 

& "From VALID_UIC Uhere VALID^UIC . F AC_ID = Any (Select " 

& "AREA„FACID.FAC_ID From AREA_FACID) Order by UIC" 

Public Const AreaC 1 osUIC(3uer y = "Select UIC Into ARE A_CL0S„UIC " 

& "From GliVNatl Uhere Tier = 'SB' and GlTNatl-UIC = Any " _ 

8 "(Select AREA_UIC.UIC From AREAJIC) Order by UIC" 

Public Const Ar eaGlfiUICZi p(3uery = "Select Distinct UICi ZipCodei " 

8 "Count(UIC) as UIC_T0TAL Into Area_Glfi_ZIP from Glfl " _ 

8 "Group by UICt ZipCode Order by UIC-i ZipCode" 

Public Const AreaGlfiUICZi pf10S(3uery = "Select Distinct UlCn ZipCodei 
8 "nos-, Count(UIC) as UIC_T0TAL Into Area„Glfl_nOS from Gift " _ 

8 "Group by UIC-, ZipCode-, HOS Order by UIC-, ZipCode-, MOS" 



S(3L (3uery Definitions (Temporary Recordsets) 



Public Const NoReqd(3uery = "Select Sum ( UIC_T0T AL) as T0TAL_RE(3D " 

8 "From GlTNatl Uhere GlTNatl-UIC = Any (Select ARE A_UIC - UIC" 

8 " From AREA_UIO" 

Public Const Dr i 1 1 Total C3uery = "Select Sum ( UIC_T0T AL) as DRILL_TOTAL " 
8 "From FINANCE. Uhere FINANCE.-UIC = Any (Select AREA.UIC-UIC " 

8 "From AREA.UIO" 

Public Const Dr i 1 1 S AT(3uery = "Select Sum (UIC.TOTAL) as TOTAL.SAT " _ 

8 "From FINANCE.CY Uhere FINANCE.CY . UIC = Any (Select AREA.UIC-UIC 
8 "From AREA.UIO" 

Public Const NoASSN(3uery = "Select Sum (UIC.TOTAL ) as TOTAL.ASSN " _ 

8 "From GlfiNatl.UIC Uhere GlfiNat l.UIC . UIC = Any " _ 

8 "(Select AREA.UIC-UIC From AREA.UIO" 

Public Const NoL0SS(3uery = "Select Sum ( UIC.TOT AL ) as TOTAL.LOSS From " 
8 "FYxxLOSS Uhere FYxxLOSS-UIC = Any (Select AREA.UIC-UIC From " _ 

8 "AREA.UIO" 

Public Const NoXFER(3uery = "Select Sum (UIC.TOTAL) as TOTAL.XFER From " 
8 "FYxxXFER Uhere FYxxXFER.UIC = Any (Select AREA.UIC-UIC From " _ 

8 "AREA.UIO" 

Public Const To tal A vai 1 Cl os(3uery = "Select Sum ( UIC.TOT AL) as " . 

8 "TOTAL.AVAIL From Area.Glfl.ZIP Uhere Area.Glfi.ZIP . UIC = " _ 

8 "Any (Select AREA.UIC-UIC From AREA.UIC) and " 

8 "Area_Glfi.ZIP. ZIPCODE = Any(Select AREA_ZIPCODE.ZIP From " . 

8 "AREA.ZIPCODE)" 



Public Const To tal IRR(3uery = "Select Count(*) as TOTAL.IRR " . 

8 "From IRR Uhere IRR.ZIP = Any (Select AREA.ZIPCODE . ZIP " 

8 "From AREA.ZIPCODE ) " 

Public Const Recru i tharke t(3uery = "Select Sum (MUC AT1E + MUCAT3A-*-" 
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a "l1BCAT15 + n0CAT3A + l1HCATia + nHCAT3A) as TOTAL_HARKET From " 
8 "UMA Uhere (JHA-ZIP = Any (Select AREA_ZIPCODE.ZIP " 

8 "From AREA_ZIPCODE)" 

Public Const Reass i gndueryBeg in = "Select Sum(UIC_TOTAL) as " 
8 "TOTAL_RESERVISTS From Area_G16_ZIP Uhere " 

8 "Area_Glfl_ZIP-UIC = '" 



Public Const ReassignflueryEnd = and Area_G16_ZIP • ZIPCODE = " 
a "Any (Select AREA_ZIPCODE.ZIP From AREA_ZIPCODE ) " 

Public Const TotalClosMOSfluery = "Select Sum(UIC_TOTAL) as " _ 

8 "T0TAL_CL0S_n0S From Area_61fl_nOS Uhere Area_G16_n0S - HOS " 
a "= Any (Select M0S_INTEREST.n0S From MOS_INTEREST) and " 

8 "Area_Gia_nOS-UIC = Any (Select AREA_CLOS_UIC ■ UIC From " 
a "AREA_CLOS_UIO and Area_Glfl_HOS . ZIPCODE = Any (Select " 

8 "AREA_ZIPCODE-ZIP From ARE A_ZIPC0DE ) " 



Public Const TotalIRR_t10S(3uery = "Select Count(IIOS) as " _ 
a "TOTAL_IRR_nOS From IRR Uhere IRR.MOS = Any (Select " 
8 "nOS_INTEREST-nOS From t10S_INTEREST)" 



Public Const ArchivedFacilitydueryBegin = "Select * From Repository Uhere FAC_ID 

— r n 

Public Const Archi vedFaci 1 i tyflueryEnd = Order by flOVUIC” 



Publ i c 
Public 
Public 
Public 
Public 
Public 
Public 
Public 
Publ ic 
Public 



Const (3def_AreaClosUICs = "Build AreaClosUIC" 
Const (3def_AreaUICs = "Build AreaUIC" 

Const (3def_AreaFacIDs = "Build AreaFacID" 

Const (3def_AreaG16UICZipf10S = "Build AreaGlfiflOS" 
Const (3def_AreaGlfiUICZips = "Build AreaGlBZip" 
Const (3def_AreaZipCodes = "Build AreaZipCode" 
Const (3def_DropTable = "Drop Table" 

Const (3def_F i nanceCY = "Build FinanceCY" 

Const (3def_f10SInterest = "Build flOSInteres t" 
Const (3def_NoASSNxM0S = "Build NoASSNxnoS" 



Acropo 1 



Public Const 
Public Const 
Public Const 
Public Const 
Public Const 
Public Const 
Public Const 
Public Const 
Public Const 
Public Const 
Public Const 
Public Const 
Public Const 
Public Const 
Public Const 
Public Const 
Public Const 
Public Const 
Public Const 



is Database Table Names 



Tbl_AreaClosUICs = "ARE A_CL0S_UIC" 
Tbl_AreaFacIDs = "AREA_FACID" 
Tbl_AreaG16UICZipnOS = " ARE A_G16_nOS" 
Tbl_AreaGlfiUICZips = "ARE A_Glfl_ZIP" 
Tbl_AreaUICs = "AREA_UIC" 
Tbl_AreaZipCodes = "ARE A_ZIPC0DE" 
Tbl_AriesArchive = "REPOSITORY" 
Tbl_CommandPlan = "CMDPLAN" 
Tbl_Complex = "C0HPLEX_" 

Tbl_ErrorLog = "ERR0R_L0G" 
Tbl_FinanceCY = "FINANCE_CY" 

Tbl_FPS = "FPS_" 

Tbl_G17Natl = "G17Natl" 

Tbl_Interest = "INTEREST." 
Tbl.nOSInterest = "flOS.INTEREST" 
Tbl.NoASSNxDOS = "NoASSNxMOS" 
Tbl.RPINFODT = "RPINFODT." 
Tbl.ValidateUIC = "VALID.UIC" 
Tbl.ValidateUnit = "VALID.UNIT" 



Public 

Public 

Public 

Public 



Const ExTbl.AreaDistance = "AreaDistance" 
Const ExTbl.AreaFacIDs = "AreaFacID" 

Const ExTbl.AreaUICs = "AreaUIC" 

Const ExTbl.PropFaci 1 i ty = "PropFacID" 



Aries OLE Class Names 



Public Const Class_LDlil = "OwlUindow" 

Public Const Class_riaplnf o = "x vt32Dmd i tasklOD" 
Public Const Class_Excel = "XLMain" 

Public Const Class_ARIES = "ThunderPorm" 

Public Const ARIES_App 1 i cat ion = "A R I E S v3 • □ " 



' Aries UinAPI3E Constants 

Public Const Sbl__Norma 1 = 3 
Public Const Sbl__ninimum = E 



' Aries Measure Table Names 

»================================================ 

Public Const conMeasureO = "Facility ID" 

Public Const conMeasurel = "Backlogged Maint" 
Public Const conMeasureE = "Operating Cost" 

Public Const conMeasure3 = "Facility Age" 

Public Const conMeasureM = "Facility Condition" 
Public Const conMeasureS = "Facility Owned" 

Public Const conMeasureb = "Competition" 

Public Const conMeasure? = "Drill Attendance" 
Public Const conMeasureS = "Area Loss Rate" 

Public Const conMeasureT = "Area Xfer Rate" 

Public Const conMeasurelD = "Avg Area Manning" 
Public Const conMeasurell = "RZA Distance" 

Public Const conMeasurelE = "Total Avail (Close)" 
Public Const conMeasurel3 = "IRR" 

Public Const conMeasurelM = "Recruit Market" 
Public Const conMeasurelS = "Reassignments" 

Public Const conMeasurelb = "AMSA Distance" 

Public Const conMeasurel? = "ECS Distance" 

Public Const conMeasurelS = "Ueekend Usage" 

Public Const conMeasurel^ = "MOS Avail (Close)" 
Public Const conMeasureED = "IRR MOS" 

Public Const conTotalMeasures = ED 
Public Const conTo talln ter imTabl es = 17 
Public Const conSing leMessages = 3 
Public Const conMax imumCol umns = M 
Public Const conFi veColumnli) idth = Tb? 

Public Const conFourColumnUidth = lElO 
Public Const conThreeColumnUidth = lb30 
Public Const conTwoColumnlilidth = EMbO 
Public Const conOneCo lumnU idth = 1370 
Public Const MeasuresFrameIndex = 0 
Public Const NonGISFrameIndex = 1 
Public Const Mapinf oFrameIndex = E 
Public Const GISNonS(3LFrameIndex = 3 
Public Const S(3LFrameIndex = M 



Aries Error Handler Codes 



Public Const ERR_0b jectEx is ts = 301E 
Public Const ERR_TableExists = 3D10 
Public Const ERR_TableNotExists = 337b 
Public Const ERR_Ex trnTabl eNot Attached = 3D7fl 
Public Const ERR_Fi 1 eNotFound = S3 
Public Const ERR_LockTabl eFai lure = 3E11 
Public Const ERR_ProgressBarMaxExceeded = 3flD 
Public Const ERR_LDlijRunning = 5 
Public Const ERR_TooFewParameters = 30bl 
Public Const ERR_InvalidUseOFNul 1 = 

Public Const ERR_NoCurrentRecord = 3DE1 
Public Const ERR_ReqdFi 1 eIndexMiss ing = 3015 
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Public Const ERR__0b jectUnloaded = 3bM 
Public Const ERR_NotVal idPath = 

Public Const ERR_Databas©AlreadyOpen = 33Sb 
Public Const ERR_ItemNotInCol lection = 32bS 

Public Const De f au 1 tErrorValue = 




Publ ic 
Public 
Public 
Public 
Public 
Public 
Public 
Public 
Public 
Public 
Public 
Public 
Public 
Public 
Public 
Public 
Public 
Public 
Public 
Publ ic 



Aries File Paths 

Const FILE_Akron = "\MS_Access\ Akron . riDB" 

Const FILE_Acropol is = ”\flS_Access\Acropo 1 is • fIDB” 

Const FILE_Acropol isBackup = ”\nS_Access\Acropo 1 i s . B AK" 
Const FILE_ria jorCi ty = "\f1apBas i cNMapInf o\Ci ty_lBS . TAB" 
Const FILE_ER0S = "\MS_Access\Eros . flDB" 

Const FILE_Excel = "\LDlil\nS_Excel\AriesTAB . TXT" 

Const FILE_GeoREF = "NMapBasicMJsarcDataNGeoref . TAB" 

Const FILE^LDlil = "C:\LDlil\LDUstud.EXE" 

Const FILE_LDU_Template = "\LDU\Template\NULL_TAB . LDld" 

Const FILE_LDbl_Excel = "\LDbl\nS_Excel\AriesTAB . TXT-" 

Const FILE_LDbl_Def aul tSave = "\LDlil\Template\De f aul t . LDlil-" 
Const FILE_LDbl_Archi veDir = "\LDlil\Archi ve\" 

Const FILE_riapBasic = "\f1apBas i c\Ar i esArch . flBX" 

Const FILE_riapInfo = "C:\nAPINFO\riapInfoU.EXE" 

Const FILE_riaplilorkspace = "NflapBasicNAriesSflL . lilOR" 

Const FILE_States = "\f1apBasic\napInf oNStates . TAB" 

Const FILE_StateCapi tals = "\f1apBas icNflapInf oNStatecap . TAB" 
Const FILE_Teliko = "\nS_Access\Tel iko . HDB" 

Const FILE_Tel ikoBackup = "\f1S_Acce ssNTe 1 i ko . B AK" 

Const FILE_Titan = "\f1S_Access\Ti tan . hDB" 



Public Const DB^ACROPOLIS = "\nS_ACCESS\ACROPOLIS.mdb" 
Public Const DB^ACROPOLISBAK = "\nS_ACCESS\ACROPOLIS . bak" 
Public Const DB^HEASURES = "\nS_ACCESS\f1easur es . mdb" 



Aries Measures (User Defined Type) 



Type f1easures_Type 

Archived As Boolean 
MovUIC^riatch As Boolean 
FacID As String * 5 
FacBack 1 ogdflaint As Single 
Operat i ngCos t As Single 
FacAge As Integer 
FacCond As String * 5 
FacOwned As String t 1 
Competition As Integer 
AreaDr i 1 1 Attend As Single 
AreaLossRate As Single 
AreaXferRate As Single 
AvgAreaflan As Single 
Dis tToRecrui t As Single 
Total Aval IClos As Integer 
IRR As Integer 
Recrui triarke t As Long 
Reassignments As Integer 
DistToAMSA As Single 
DistToECS As Single 
FacblkndUsed As Byte 
flOSA vai 1 Clos As Integer 
IRR_f10S As Integer 
End Type 

Type flovingUni t_Type 
UIC As String * t. 

FacID As String * 5 
UnitName As String 
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City As String 
State As String * 2 
ZipCode As String * 5 
End Type 

Type Faci 1 i ty_Type 

FacID As String * 5 
City As String 
State As String * E 
ZipCode As String * 5 
End Type 

Type Inf oToo l_Type 

flapTable As String 
GeoFacID As String 
End Type 
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Module 4. ARIES PROCEDURES LIBRARY 



Purpose: A library module that contains all the procedures called by other procedures more 

than one time. 

Source Type; Visual Basic for Applications 
Source File; LIBRARY.BAS 
Code Listing: 



Attribute VB_Name = "libPROCEDURES" 

Declare Function GetC lassNameS Lib '’user3E” Alias "GetC lassNameA'’ _ 

(ByVal hwnd As Longi ByVal IpClassName As Stringi ByVal nMaxCount As Long) 

Declare Function ShowblindowS Lib "user3E" _ 

(ByVal hwnd As Longn ByVal nCmdShow As Long) 

Declare Function FindUindow& Lib "user3E" Alias "FindUindowA" _ 

(ByVal IpClassName As Stringi ByVal IpU indowName As String) 

Public Function KeyUpperNumeric ( nKeyVal As Integer) As Integer 
cProcName = "FUNC : KEY_UPPER_NUMERIC" 

'Passes Uppercase Letters 
'Converts Lowercase to Uppercase 
'Passes CDt1tEt3tM T 5Ttn7TfiTT} & Cntrl Codes 
'REJECTS ALL else 

If nKeyVal > Eb Then 

If Chr(nKeyVal) >= "a" And Chr(nKeyVal) <= "z” Then 
nKeyVal = nKeyVal - 3E 
End If 

If Chr(nKeyVal) >= "A" And Chr(nKeyVal) <= "Z" Then 
nKeyVal = nKeyVal 
Else 

nKeyVal = KeyNumeri c ( nKeyVal ) 

End If 
End If 

KeyUpperNumer ic = nKeyVal 
End Function 

Private Function KeyNumeri c ( nKeyVa 1 As Integer) As Integer 
cProcName = "FUNC : KE Y.NUHERIC" 

Dim cVal idNumer ic As String 

cValidNumeric = "DlE3MSb?a^” 

If nKeyVal > EL Then 

If InStr ( cVal idNumer ic T Chr ( nKeyVal ) ) = 0 Then 
nKeyVal = D 
End If 
End If 

KeyNumeric = nKeyVal 
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End Function 



Public Function Va 1 idateflovUIC ( By Val cUIC As String) As Boolean 
cProcName = "FUNC : VALIDATE^HO VUIC" 

Dim rs Val idatellovUIC As Recordset 

'Develop Criteria for Search 
Val ida teflovUIC = True 

'Open Validation Table 

Set rs Val ida teflovUIC = db Acropo 1 is . OpenRecordse t ( Tbl_Va 1 idateUIC i 
dbOpenTablei dbReadOnly) 

With rs Val idateflovUIC 
•Index = "UIC" 

.Seek " = cUIC 

'Examine Table for first occurance of Moving Unit UIC 
If -NoMatch Then 

Val idateMovUIC = False 

Else 'Get Facility Information 

cMovU i c • FacID = !Fac_ID 
cMovU i c • Un i tName = lUnitName 
cMovUic*City = !City 
cMovU i c • State = !State 
cMovUic . ZipCode = !Zip 
End If 
•Close 
End With 

'Delete Recordset Object 
Set rs Val idateMovUIC = Nothing 

End Function 

Public Function Val idateFacID (By Val cFacID As Stringi _ 

ByRef rsVal idateFacID As Recordset) As Boolean 
cProcName = "FUNC : VALIDATE_FACID” 

'Develop Criteria for Search 
rs Val idateFacID . Seek " = cFacID 

'Examine Table for first occurance of FACID 
If rsVa 1 idateFacID • NoMatch Then 
Val idateFacID = False 
Else 

Val idateFacID = True 
End I f 

End Function 

Public Function Compu teFaci 1 i tyAge ( By Va 1 DateAcquired As Date) As Integer 
cProcName = "FUNC : COMPUTE_FACILITY_AGE" 

Dim PresentDate As Date 

On Error Resume Next 

'Minimum Facility Age Value (Default) 

ComputeFaci 1 i tyAge = □ 

'Today's Date 
PresentDate = Now 

If IsDate ( DateAcquired ) Then 'Valid Date 

ComputeFaci 1 ityAge = DateDif f (”m" -» DateAcquired t PresentDate) 

End If 

End Function 

Public Function DisplayMessage (ByVal cMsgText As Stringi _ 

ByVal iMsgIcon As ByteT ByVal iMsgBtn As Byte-i _ 
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cPIsgCaption As String) As Integer 

Displayflessage = HsgBox ( cNsgTex t n irisglcon + iflsgStn-. cflsgCaption) 

End Function 

Private Function FormatTi me ( By Val iTime As Long) As String 
Dim iHour As Long 
Dim ininute As Long 
Dim iSecond As Long 
Dim iRemainder As Long 

FormatTime = c(3ueryS tartTi me 

iHour = iTime \ 3L0Q 

iRemainder = (iTime - (iHour * 3L0Q)) 

ininute = iRemainder \ LD 

iSecond = iRemainder - (ininute t bO) 

If Len ( CStr ( iHour ) ) = 2 Then 
FormatTime = CStr(iHour) & 

Else 

FormatTime = "D" & CStr(iHour) a 
End If 

If Len ( CStr ( ininute ) ) = 2 Then 

FormatTime = FormatTime a CStr ( ini nute ) a 
Else 

FormatTime = FormatTime a "0" a CStr ( in inute ) a 
End If 

If Len (CStr ( iSecond) ) = 2 Then 

FormatTime = FormatTime a CStr ( iSecond ) 

Else 

FormatTime = FormatTime a "0” a CStr ( i Second ) 

End If 

End Function 

Public Function TableNotNULL ( ByRef rsRecord As Recordset) As Boolean 
cProcName = "FUNC : T ABLE_N0T_NULL” 

On Error Resume Next 

TableNotNULL = True 

If rsRecord • Abso lutePos i ti on = -1 Then 
TableNotNULL = False 
End If 

End Function 

Public Function (3uerySumNo tNULL ( By Val cSumResult As Variant) As Boolean 
cProcName = '’FUNC : (3UER Y_SUn_NOT_NULL" 

On Error Resume Next 

(3uerySumNotNULL = True 

If IsNull (cSumResult) Then 
(3uerySumNo tNULL = False 
End If 

End Function 

Public Function (JueryCountNo tNULL ( By Val cSumResult As Variant) As Boolean 
cProcName = "FUNC : t3UER Y_C0UNT_N0T_NULL" 



On Error Resume Next 
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(3ueryCoun tNo tNULL = True 



If cSumResult = □ Then 

(SueryCountNo tNULL = False 
End If 

End Function 

Public Sub Traf f i cL ight ( By Val Color As Long) 
cProcName = "TRAFFIC_LIGHT” 

With frmAriesflain 
Select Case Color 
Case vbRed 

! shpRedLi te . Fi 1 ICo lor = Color 
! shpYellowLite -FillColor = vbBlack 
! shpGreenLite • FillColor = vbBlack 
! cmdAriesBtn • Enabled = False 
Case vbYellow 

! shpRedLi te • Fi 1 IColor = vbBlack 
! shpYe 1 lowLi te • Fi 1 ICo lor = Color 
! shpGreenL i te • Fi 1 1 Co 1 or = vbBlack 
! cmdAriesBtn . Enabled = False 
Case vbGreen 

! shpRedLite • Fi llColor = vbBlack 
! shpYel 1 owL i te . F i 1 1 Co 1 or = vbBlack 
! shpGreenLite . FillColor = Color 
IcmdAriesBtn-Enabled = True 
Case vbBlack 

! shpRedLite . Fi 1 1 Co lor = Color 
! shpYellowLite .FillColor = Color 
! shpGreenL i te . F i 1 1 Co lor = Color 
! cmdAriesBtn . Enabled = False 
End Select 
End lilith 

End Sub 

Public Sub GetPropFacilityInfo (ByRef cFaci 1 i tyinf o As Faci 1 i ty_Type *• 
ByRef rs Faci 1 i ty Data As Recordset) 
cProcName = ”GET_FACILITY_INFO" 

Dim bVa 1 idFaci 1 i ty As Boolean 

On Error GoTo EH_Ge tPropFacInf o 

bValidFacility = ValidateFacIDCcFacilitylnfo-FacID-i rsFacilityData) 

If bValidFacility Then 
Uith cFaci 1 i tyinf 0 

•City = rsFaci lityData ! City 
•State = rsFaci 1 i tyData ! State 
•ZipCode = rsFaci 1 i tyData ! Zip 
End Uith 

Call LoadPropFacilityUICBox(cFacilitylnfo-FacID) 

End If 

Exit Sub 

EH_Ge tPropFacInf 0 : 

Select Case Err. Number 

Case ERR.InvalidUseOFNull 
Resume Next 

Case Else 'Trap all other Errors & Report 
Call 0utputERR0R_L0G 
Resume Next 
End Select 
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End Sub 



Public Sub DisplayPropFaci 1 i tyinf o (ByRef cFacility As Fac i 1 i ty_Type ) 
cProcName = '’DISPL AY_FACILITY_INFO" 

With frmAriesriain 

! tx tPropFacID • Text = cFaci 1 i ty . FacID 
! tx tCi ty • Tex t = cFaci 1 i ty . C i ty 
! tx tState . Tex t = cFac i 1 i ty - S tate 
! tx tZ ipCode • Text = cFaci 1 i ty • ZipCode 
End With 

Call DisplayPropFacilityUnitNames 
End Sub 

Public Sub LoadPropFaci 1 i tyUICBox (ByRef cFacID As String) 
cProcName = "GET_PR0P0SED_F ACILITY_UIC_INFO" 

Dim i As Integer 

Dim rsFaci 1 i tyUICs As Recordset 

Set rsFaci 1 i tyUICs = dbAcropo 1 i s • OpenRecordse t ( Tb l_Val i dateUIC t dbOpenTablei 
dbReadOnly ) 

frmAriesriain!cboUIC*Clear 
(Jith rsFaci 1 ityUICs 
• HoveFi rst 
Do Until -EOF 

If cFacID = !Fac_ID Then 

f rmAr i esflain ! cboUIC • Additem !UIC 
End If 
•HoveNext 
Loop 
• Close 
End With 

'Test whether any Units are assigned 
Uith frmAriesflain 

If Not ! cboUIC - L i stCount = Q Then 
IcboUIC-Text = ! cboUI C . Li s t ( □ ) 

Else 

IcboUIC.Text = "-NONE-" 

End If 
. Refresh 
End Uith 

Set rsFaci 1 i tyUICs = Nothing 
End Sub 

Public Sub D i splayP ropFac i 1 i tyUn i tNames ( ) 

cProcName = "DISPL AY_PR0P0SED_F ACILIT Y_UNITN AMES" 

Dim i As Integer 

Dim rsFaci 1 i tyinf o As Recordset 

Dim rsFaci 1 i tyUni t As Recordset 

Set rsFaci 1 ityinfo = dbAcropol i s . OpenRecordset (Tbl_Val idateUIC i dbOpenTablei 
dbReadOnly ) 

Uith frmAriestlain 

rsFaci 1 ityinfo • Index = "UIC" 

! IstbxUnitName-Clear 

If Not ! cboUIC • ListCount = □ Then 

For i = □ To ! cboUIC • L i StCount - 1 

rsFac i 1 i tyinf o . Seek "="t ! cboUIC . List ( i ) 

If Not rsFaci 1 i tyin fo . NoHatch Then 

! 1 stbxUni tName • Additem rsFaci 1 i tyinf o ! UIC & vbTab _ 

& rsFaci 1 i tyinf o ! Un i tName 

End If 
Next i 
Else 
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!cboUIC.Text = "-NONE-” 

Set rsFac i 1 i tyUni t = dbAcropol i s . OpenRecordse t ( Tbl_Val idateUni t 
dbOpenTablei dbReadOnly) 

rsFacil ityUnit . Index = "FACID" 

rsFaci 1 i tyUni t . Seek ! tx tPropFacID . Tex t 

If rsFac i 1 i tyUni t . Noflatch Then 

! IstbxUnitName. Additem NOT AVAILABLE 

Else 

! IstbxUnitName. Additem rsFacilityUnit!UnitName 
End If 

rsFacilityUnit-Close 
End If 
.Refresh 
End lilith 

rsFacilityInfo.Close 
Set rsFaci 1 i tyinf o = Nothing 
Set rsFacili tyUnit = Nothing 
End Sub 

Public Sub DisplayTreeViewInf 0 (ByRef tflapFacIDs ( ) As In f oToo l_Type t _ 

ByVal Index As Long) 

cProcName = "PISPL AY_TREEVIEU_INFO" 

Dim rsFac i 1 i tyUICs As Recordset 

Dim bUICExists As Boolean 

Dim nodeGIS As Node 

Dim i As Integer 

Dim j As Integer 

Dim cFacID As String * 5 

ReDim cKey(Index) As String * 5 

Set rsFac i 1 i tyUICs = dbAcropol is . OpenRecordset ( Tbl_Val idateUIC t dbOpenTablei 
dbReadOnly) 

lilith frmAriesflain 

! trvGISData . Enabled = True 

Set nodeGIS = ! trvGISData . Nodes . Add ( -. "ROOT"-. "US ARC : GeoREF" ) 

For i = Clnt(Index) To 1 Step -1 
cKey(i) = tflapFacIDs ( i ). GeoFacID 
cFacID = tflapFacIDs ( i ). GeoFacID 

Set nodeGIS = ! trvGISData . Nodes . Add ( "ROOT" tvwChildi CStr (cKey ( i ) ) t 
cFacID ) 

nodeGIS . Expanded = True 

bUICExists = False 
rsFacilityUICs.floveFirst 
Do Until rsFaci 1 i tyUICs . EOF 

If cFacID = rsFaci 1 i tyUICs ! Fac_ID Then 

Set nodeGIS = ! trvGISData . Nodes . Add (cKey ( i ) i tvwChild-. 
rsFacilityUICs.'UIC) 

nodeGIS . Expanded = True 
bUICExists = True 
End If 

rsFacilityUICs.floveNext 

Loop 

If Not bUICExists Then 

Set nodeGIS = ! trvGISData . Nodes . Add ( cKey ( i ) -. tvwChild-. -. "None") 
nodeGIS . Expanded = True 
End If 
Next i 

nodeGIS. E ns ureVisible 
. Refresh 

rsFacilityUICs-Close 
Set rsFaci 1 i tyUICs = Nothing 
End lilith 
End Sub 
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Public Sub LoadHo vUIC 1 i s tbox ( ByRef cHovUic As Hov i ngUn i t_Type ) 
cProcName = ”L0 AD_nOVUIC_LISTBOX” 

Dim iUni tNameLeng th As Byte 
Dim cUnitName As String 

cUnitName = cHovU ic • Uni tName 
iUni tNameLeng th = Len (cUnitName) 

With f rmAriesHain ! IstbxflovUIC 
. Clear 

•Enabled = True 

•Addltem "FacID: " & cHovUic • FacID 

• Addltem " ” 

If iUn i tNameLeng th > Ifl Then 
•Addltem Lef t (cUnitNamen Ifl) 

If iUn i tNameLength > 3L Then 

• Addltem h id ( cUn i tName i Ifl) 

• Addltem Right (cUnitNamen ( iUn i tNameLeng th - 3D) 

Else 

• Addltem Right (cUnitName-. ( iUn i tNameLeng th - Ifl)) 

End If 

Else 

•Addltem cUnitName 
End If 

• Addltem " ” 

•Addltem chovUic^City 

•Addltem cHo vU i c • State & " & cHovUic • ZipCode 

End With 
End Sub 

Public Sub LoadFac i 1 i tyListBox (ByVal Index As Integer-. ByVal rsValidFacID 
As Recordset-. ByVal iUIC_Flag As Byte) 
cProcName = "LO AD_FACILITY_LISTBOX" 

Dim iUni tNameLength As Byte 
Dim cUnitName As String 

cUnitName = rsVal idFacID ! Uni tName 
iUni tNameLength = Len ( cUn i tName ) 

'Display Facility specific information 
With frmAriesHain! lstbxFacID( Index) 

• Cl ear 

•Enabled = True 
If iUIC_Flag = D Then 

•Addltem "UIC: " a rsVal idFacID ! UIC 
Else 

•Addltem ”UIC: " a "-NONE-” 

End If 

• Addltem " " 

'Parse Unitname to fit Listbox w/out needing scrollbars 
If iUnitNameLength > Ifl Then 

• Addltem Lef t ( cUni tName -. Ifl) 

If iUnitNameLength > 3L Then 

• Addltem hid ( cUni tName -. 1'^-. Ifl) 

• Addltem R ight ( cUn i tName -. (iUnitNameLength - 3D) 

Else 

• Addltem R ight ( cUni tName -. (iUnitNameLength - Ifl)) 

End If 

Else 

•Addltem cUnitName 
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End If 



'Display Cityi State-i Zip information 

-Addltem " " 

-Addltem rsVal idFacID ! City 

•Addltem rsVa 1 idFacID ! State 8 "t "8 rsVal idFacID ! Zip 
End With 
End Sub 

Public Sub D i spl ayS tatus ( By Val cflessage As Stringi Index As Byte) 

With frmAriesf1ain!fraStatus(Index) 

If Not -Enabled Then 
•Enabled = True 

• Refresh 
End If 

End Uith 

With f rm Arie sH ain ! Is tbxStatus (Index) 

If Not (.Visible) Then 
•Visible = True 

• Re fresh 
End If 

If Not (Len( frmAriesriain ! txtStatus (Index ) ) = 0) Then 

• Addltem frmAriesllainltxtStatusdndex) .Text 

• Re fresh 
End If 

End With 

bJith frmAriesllainltxtStatusdndex) 

• Text = cllessage 

• Re fresh 

If Not (cHessage = CompletellSC) Then 
Call IncrementProgressBar 
Else 

•Enabled = False 
•Refresh 
End If 
End With 

Call E lapsedTimer ( Time$ ( ) ) 

End Sub 

Public Sub IncrementProgressBar ( ) 

On Error Resume Next 

iProgressIndicator = iProgressIndicator + 1 
f rmAr i esHain ! barSflLstatus . Value = iProgressIndicator 
f rmAriesHa in !fraS(3Lstatus - Refresh 
End Sub 

Public Sub Bui IdAccessTabl e ( ByVal cTableName As String-i cfldefnName As Stringi 
cfldefText As String) 
cProcName = "BUILD_ACCESS_T ABLE" 

Dim qdS(3L As (3ueryDef 

On Error GoTo EH_Bui IdTabl e 

'Build S(3L fluery definition for Recordset Object 

Set qdS(3L = dbAcropol i s • CreateflueryDef ( cfldef nName t cfldefText) 

dbAcropo 1 i s . Execute cfldefnName 

'Delete fluery Definition 8 Table 
dbAcropol is. flueryDefs. Delete cfldefnName 

Exit Sub 
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EH_Bui IdTable : 'Error Handler 

Select Case Err. Number 

Case ERR_0b jectEx ists 'Delete the Pre-Existing (Juery Definition 
dbAcropolis.flueryDefs.Delete c(3defnName 
Resume 

Case ERR_TableExists 'Delete the Pre-Existing Table 
Call DeleteAccessTable(cTableName) 

Resume 

Case Else 'Trap all other Errors & Report 
Call OutputERROR_LOG 
Resume Next 
End Select 
End Sub 

Public Sub De 1 e t e AccessTabl e ( By Va 1 cTableName As String) 
cProcName = "DELETE_ACCESS_T ABLE" 

Dim qdDropTable As CJueryDef 
Dim cDropTab leDe f n As String 

On Error GoTo EH_De le teTab le 

cDropTableDef n = "Drop Table " & cTableName 

Set qdDropTable = dbAcropol is . CreateflueryDe f ( (3def_DropTabl e t cDropTableDef n ) 
dbAcropol is. Execute (3de f_DropTab 1 e 

dbAcropolis.flueryDefs.Delete Ode f_DropTab 1 e 

Exit Sub 

EH_Dele teTab le : 

Select Case Err. Number 
Case ERR_0b jectExists 

dbAcropolis.OueryDefs.Delete Odef_DropTab le 
Resume 

Case ERR_TableNotEx ist s 
Resume Next 

Case Else 

Call OutputERROR_LOG 
Resume Next 
End Select 
End Sub 

Public Sub E 1 apsedT imer ( ByVal cTime As String) 

Dim iHourNou As Long 
Dim iriinuteNou As Long 
Dim iSecondNou As Long 

Dim iStartHour As Long 
Dim iStartflinute As Long 
Dim iStartSecond As Long 

Dim iElapsedTime As Long 
Dim iStartTime As Long 
Dim iNowTime As Long 

Dim cElapsedTime As String * 6 

iHourNou = CLng (Lef t (cTime t E)) 
iriinuteNou = CLng ( Hid ( cTime i Mt E)) 
iSecondNou = CLng ( R ight ( cTime i E)) 

iStartHour = CLng ( Lef t (cOueryStartTime t E)) 
iStartninute = CLng (Hid ( cOueryStartTime i Mi E)) 
iStartSecond = CLng (Right (cOueryStartTime i E)) 
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iStartTime = (iStartHour * 3LDD) + ( iStartflinute * bD) + iStartSecond 
iNowTime = (iHourNow * 3L0D) + (iHinuteNow * bD) + iSGCondNow 

iElapsedTime = iNowTime - iStartTime 

cElapsedTime = FormatTime ( iE lapsed! ime ) 

Uith frmAriesnain 

! AriesStatusBar. Panels (3) . Text = "Elapsed " S; cElapsedTime 
. Refresh 
End With 
End Sub 

Public Sub T imeDe 1 ay ( ByVal cTime As String-» _ 

ByVal iTimeDelay As Integer) 
cProcName = "TiriE_DELAY" 

Dim iSecond As Integer 
Dim iflinute As Integer 
Dim iNowMinute As Integer 
Dim iNowSecond As Integer 

Dim iExitTime As Integer 
Dim bRol loverFlag As Boolean 

bRol 1 0 verFlag = False 

iSecond = CInt ( R ight ( cTime i E)) 

iflinute = CInt ( fl id ( cTime -• Mi E)) + 1 

iExitTime = iSecond + iTimeDelay 
If iExitTime > 5T Then 

iExitTime = iExitTime - ST 
bRo 1 1 overFlag = True 
End If 

iNowSecond = CInt ( Right ( Time$ () i E)) 

If bRo 1 loverFlag Then 

iNowflinute = CInt (hid ( Time$ () i Mi E)) 

Do 

iNowflinute = CInt (flid ( Time$ ( ) i Mi E) ) 
iNowSecond = CInt (Right ( Time$ () i E)) 

Loop While iNowflinute < iflinute 
Else 
Do 

iNowSecond = CInt ( R i ght ( Time$ ( ) i S)) 

Loop While iNowSecond < iExitTime 
End If 
End Sub 
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Module 5. OLE PROCEDURES LIBRARY 



Purpose; A library module that contains all the procedures supporting OLE 
communications between COTS components. 



Source Type: Visual Basic for Applications 



Source File; OLE_LIBRARY.BAS 



Code Listing: 

Attribute VB_Name = "libOLE'’ 

Option Explicit 

Public Function ConnectOLEob ject (ByRef objOLE As Objecti ByVal cOLEob jectName 
As String) As Boolean 
cProcName = "FUNC : 0PEN_0LE_0B JECT" 

On Error Resume Next 

'Set Boolean Flags 
ConnectOLEob ject = True 
Set objOLE = Nothing 

'Initiate a new instance 

Set objOLE = CreateOb ject ( cOLEob jectName) 

'Verify OLE connection established 
If objOLE Is Nothing Then 'OLE Error 

Call Displayhessage (OLEf ai ledflSGi vbExclamati on t vbOKi conOLEcaption ) 
ConnectOLEob ject = False 
Else 

objOLE • Visible = False 
End If 

DoE vents 

End Function 

Public Function OpenLDliJobject() 

cProcName = "FUNC : 0PEN_LDU_0B JECT" 

Dim cFilePath As String 

On Error GoTo EH_OpenLDU 

OpenLDU object = True 
cFilePath = FILE^LDU 

'Determine if an Instance of LDli) already running 
iLDUwinID = F indU i ndow ( C lass_LDli) i vbNul IS tring ) 

If iLDUwinID Then 

Call ResetLDUob ject 
Else 

iLDUwinID = Shel 1 ( cFi lePathi vbNormalFocus ) 
f rmAri esflai n ! mnuFCloseLDU . Enabled = True 
'Clear LDU Splash Screen 
SendKeys "~"t True 
End If 



'LDU Failed to Load properly. 



EH_OpenLDU: 

OpenLDUob ject = False 
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End Function 



Public Function VerifyLDbjobjGCtConnectionCByVal cHessageText As String) As 
Boolean 

Dim iLDU_hlilnd As Long 

iLDlil_hUnd = Findlilindow ( Class_LDbl i vbNul IString ) 

If iLDU_h(Jnd = 0 Then 

Veri f yLDblob jec tConnection = False 

Call D isplayflessage ( cMessageText T vbCriticali vbOKOnlyn conAPIcapt i on ) 
Else 

Veri f yLDblob jectConnection = True 
ShowbJindow iLDb)_hUndT Sbl_Hinimum 
ShoubJindow iLDb)_hb)ndT Sbl_Normal 
End If 

End Function 

Public Sub Ini t ial i zeMapInf oflenu ( ) 
cProcName = "INITI ALIZE_nAP_nENU" 

ob jGeoSe lect . Do "Create flenu ""flapperShortcu t"" ID 17 As " 

End Sub 

Public Sub Ini t ial i zeflaplnf oToo Ibar ( ) 
cProcName = "INITI ALIZE_nAP_TOOL_BAR" 

ob jGeoSelect . Do "Create ButtonPad ""InfoTool"" As " & _ 

"ToolButton ID 5D1 Drawflode 3M Calling OLE ""Processinf oToo IButton""" 



End Sub 

Public Sub In i t ia 1 izeflaplnf oStatusBar ( ) 
cProcName = "INITI ALIZE_riAP_STATUS_BAR" 

ob jGeoSe lect ■ Do "Set flap Display Zoom" 

ob jGeoSe lect . Do "Alter flenu Item ID 1101 Check" 

ob jGeoSe lect • Do "Alter Menu Item ID IIDE UnCheck" 

ob jGeoSe lec t . Do "Alter Menu Item ID 1103 UnCheck" 

End Sub 

Public Sub OpenUS_StatesLayer ( ) 

cProcName = "DISPL A Y_US_STATES_L AYER" 

Dim cFilePath As String 

cFilePath = Chr(3M) & App.Path & FILE_States & Chr(3M) 
ob jGeoSelect • Do "Open Table " & cFilePath & " Interactive" 

End Sub 

Public Sub OpenUSARC_GeoRef Layer ( ) 

cProcName = "DISPL A Y_USARC_GEOREF_LA YER" 

Dim cFilePath As String 

cFilePath = Chr(3M) & App.Path & FILE_GeoREF & Chr(3M) 
ob jGeoSe lect . Do "Open Table " & cFilePath & " Interactive" 

End Sub 

Public Sub OpenStateCapi talsLayer ( ) 

cProcName = "DISPLA Y_STATE_CAPITALS_L A YER" 

Dim cFilePath As String 

cFilePath = Chr(3M) & App.Path & FILE_S tateCapi tal s & Chr(3M) 
ob jGeoSelect . Do "Open Table " & cFilePath & " Interactive" 
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End Sub 



Public Sub Openfla jorC i tyLayer ( ) 

cProcName = "DISPLA Y_riA JOR_CITIES_L A YER” 

Dim cFilePath As String 

cFilePath = Chr(3M) S; App.Path S; FILE_f1a jorC i ty & Chr(3M) 
ob jGeoSe lect . Do '’Open Table ” & cFilePath s; " Interactive" 

End Sub 



Public Sub DisplayflapLabels ( ) 

cProcName = "DISPLAY_riAP_L ABELS" 

ob jGeoSe 1 ect - Do "flap From Statecapi City_lESn Georefn States" 
iflapinf oUi nID = CLng ( ob jGeoSelect . Eval ( "FrontUindow ( ) " ) ) 
ob jGeoSelect - Do "Set flap Redraw Off" 

'State Capitals layer Labels S Symbols 

ob jGeoSel e ct . Do "Set flap Layer ""Statecap"" Display Global Selectable Off " 
ob jGeoSelect - Do "Set flap Layer ""Statecap"" Label Auto On Overlap On " & _ 
"Duplicates On Uith Proper^ ( Capi tal) " 
ob jGeoSe 1 ect • Do "Set flap Layer ""Statecap"" Label Line Simple " _ 

& "Position Above Offset 3 Font (""Arial""-. 603 fl3aflfc,Da lb777ElS ) " 

& "Global Symbol (3S-. lL7]ilbaDn la) " 
ob jGeoSe 1 ect • Do "Set flap Layer ""Statecap"" Label Visibility Zoom (MDDn 
EDDD)" 

& " Units ""rni""" 

'flajor City layer Labels Z Symbols 

ob jGeoSelect ■ Do "Set flap Layer ""City_lES"" Display Global Selectable Off " 
ob jGeoSelect . Do "Set flap Layer ""Ci ty_lES"" Label Auto On Overlap On " & _ 
"Duplicates On With Proper^ ( Ci ty ) Zoom (D-i 3DDD) Units ""mi"" On " 
ob jGeoSel ect . Do "Set flap Layer ""City_lES"" Label Line Simple " __ 

Z "Position Above Offset 3 Font (""Arial""-« ETl n ID -ilt.77bTtiD tD ) " _ 

Z "Global Symbol (Mb. lb77bTbD-. IE) " 
ob jGeoSe 1 ect - Do "Set flap Layer ""C i ty_lES"" Label Visibility Zoom (ESD-i 
!□□□)" 

Z " Units "”mi""" 



'GeoREF layer Labels S; Symbols 

ob jGeoSelect • Do "Set flap Layer ""Georef"" Display Global Selectable On " 
ob jGeoSe 1 ect . Do "Set flap Layer ""Georef"" Label Auto On Overlap On " & _ 
"Duplicates Off With Proper^ (Fac_ci ty ) Zoom (□■• SOD) Units ""mi"" On " 
ob jGeoSe 1 ect . Do "Set flap Layer ""Georef"" Label Line Simple " __ 

Z "Position Above Right Offset 3 Font (""Arial""-. aU3 ID 3E7fc,fl lt,777ElS ) " 



Z " Pen (E-.m.3E7ba) Global Symbol (MS-. 3E7t,fi-. Ifi) " 
ob jGeoSe 1 ect . Do "Set flap Layer ""Georef"" Label Visibility Zoom (□-. 7DD) " _ 
Z "Units ”'’rni""" 



'States layer Labels 
ob jGeoSe lect - Do "Set flap Layer 
ob jGeoSe lect - Do "Set flap Layer 
Z "Duplicates On Offset □ " 
ob jGeoSe 1 ect • Do "Set flap Layer 
ob jGeoSelect • Do "Set flap Layer 

Z "iaE7-,ia-.D-.]ib777E15) " 
ob jGeoSel ect ■ Do "Set flap Layer 



""States"" 


Selectable 


Off Label Line 


Simple " 


""States"" 


Label 


Auto 


On Overlap On " 


- 


""States"" 


Label 


Uith 


Proper^ ( Sta te ) 


n 


""States"" 


Label 


Font 


(""Bookman Old 


style""-." 


""States"" 


Label 


Visibility Zoom (IDD 


1 2DDD) " 



Z "Units 



ob jGeoSelect ■ Do "Set flap Redraw On" 
End Sub 



Public Sub Pos i t i onflap ( ) 
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cProcName = "P0SITI0N_nAP" 

ob jGeoSelect . Do "flap From Statecapi City_lE5T Georefi States" 
ob jGeoSelect • Do "Set flap Center (-Ttn37) Zoom 3SDD Units ""mi""" 
ob jGeoSelect - Do "Set flap Layer □ Editable On" 

End Sub 

Public Sub flaplnf o(3uery (ByVal cFacID As String) 
cProcName = "fl APINF0_(3UER Y" 

Dim i As Byte 'Loop Variable 

Dim cFilePath As String 

Dim rsProposedFac i 1 i ty As Recordset 

Set rsProposedFacility = dbAcropolis . OpenRecordset (ExTbl_PropFacil ityi 
dbOpenDynase t ) 

With rsProposedFaci 1 i ty 

'Delete Previous Proposed Facilities 
Do Until .EOF 
•Delete 
. HoveNe X t 
Loop 

'Output Proposed Facility ID to External Database 
. AddNew 

!Fac_ID = cFacID 
. Update 
•Close 
End With 

Set rsProposedFaci 1 i ty = Nothing 

ob jGeo(3uery . Vis ible = True 
If Not bflapBas icRunn ing Then 

cFilePath = Chr(3M) & App.Path & FILE_napUorkspace & Chr(3M) 
ob jGeo(3uery . Do "Run Application " 2 , cFilePath 
End If 

cFilePath = Chr(3M) a App.Path a FILE_riapBas i c a Chr(3M) 
f rmAriesMain ! tabAr iesMap . Tab = 1 

ob jGeofiuery . Do "Run Application " a cFilePath 
bflapBas icRunning = True 

Call Di splayStatus ( AreaGlflMSG 1 GISNonS(3LFrameIndex ) 

Call DisplayStatus ( ArealRRnSGi GISNonSflLFrameIndex ) 

Call DisplayStatus ( AreaflriAnSGi GISNonS(3LFrameIndex ) 

End Sub 

Public Sub OutputAriesfleasuresExcel (ByRef arieasures() As f1easures_Type t ByVal 
iFacIndex As Byte) 

cProcName = "OUTPUT_ARIES_nE ASURES^EXCEL" 

Dim objUorkSht As Object 
Dim cFilePath As String 

Dim i As Byte 
Dim j As Byte 

On Error GoTo EH_Exce Ifleasures 

Screen . HousePointer = vbHourglass 

If ConnectOLEob ject ( ob jExce 1 n "Exce 1 • Appl icat i on" ) Then 
objExcel . Visible = True 
objExcel . Workbooks. Add 

Set objlilorkSht = objExcel • ActiveSheet 
With objliJorkSht 



234 



• cellsCl-. 


1) . 


Value 


= 


"ALTERNATIVES 


• cel Is (2 1 


1) . 


Value 


= 


"NAME" 


• cellsCE-. 


2) . 


Value 


= 


"NUMBER" 


. cel Is ( 2 T 


3) . 


Value 


= 


"NUMBER" 


. cel 1 s ( 2 T 


^) . 


Value 


= 


"NUMBER" 


. ce 1 1 s ( 2 T 


5) . 


Value 


= 


"NUMBER" 


.cells(2-. 


b) . 


Value 


= 


"NUMBER" 


.cells(2-. 


7) . 


Value 


= 


"LABEL" 


. ce 1 1 s ( 2 T 


fl) . 


Value 


= 


"NUMBER" 


. ce 1 1 s ( 2 T 


T) . 


Value 


= 


"NUMBER" 


• ce 1 1 s ( 2 T 


ID) 


. Value 


= 


"NUMBER" 


- cel Is (2 T 


11) 


• Value 


= 


"NUMBER" 


. cel Is (2 T 


12) 


• Value 


= 


"NUMBER" 


.cells(2-. 


13) 


.Value 


= 


"NUMBER" 


.cells(2-, 


IM) 


•Value 


= 


"NUMBER" 


. cel Is (2 T 


15) 


• Value 


= 


"NUMBER" 


• cells(2-. 


lb) 


•Value 


= 


"NUMBER" 


.cells(2-. 


17) 


• Value 


= 


"NUMBER" 


.cells(2-. 


17) 


• Value 


= 


"LABEL" 


.cells(2-, 


Ifl) 


• Value 


= 


"NUMBER" 


.cells(2-. 


n) 


• Value 


= 


"NUMBER" 


.cells(2-. 


2D) 


•Value 


= 


"NUMBER" 


• cells(2-. 


21) 


•Value 


= 


"NUMBER" 



'Output Measure Titles for LDU Import 



cells(3-. 


1) . 


Value = 


"NAME" 


cells(3-. 


2) . 


Value = 


"Cl osing_Un i t_Xf ers" 


cel Is ( 3 T 


3) . 


Value = 


"Avail_MOS_ClosUni ts" 


cel 1 s ( 3 T 


M) . 


Value = 


"IRR_Available" 


cells(3i 


5) . 


Value = 


"Avail_MOS_IRR" 


ce 1 1 s ( 3 T 


b) . 


Value = 


"Fac_Age" 


ce 1 1 s ( 3 T 


7) . 


Value = 


"Fac_0wned" 


ce 1 1 s ( 3 T 


fl) . 


Value = 


"Fac_Operat ing_Cos ts" 


ce 1 1 s ( 3 T 


T) • 


Value = 


"Dist_to AMSA" 


cells(3-. 


ID) 


•Value = 


"Dist_to_ECS" 


ce 1 1 s ( 3 T 


11) 


•Value = 


"Area_T rans f er_Rate" 


ce 1 1 s ( 3 T 


12) 


•Value = 


" A V g_A r e a_M a n n i n g " 


ce 1 1 s ( 3 T 


13) 


•Value = 


"Area_I)ri 1 l_Attendnc" 


cells(3-, 


IM) 


•Value = 


"Dist-to-Recruiter" 


ce 1 1 s ( 3 T 


15) 


•Value = 


"Recrui t_Market" 


cel 1 s ( 3 T 


lb) 


•Value = 


"Reassignments" 


cells(3-. 


17) 


•Value = 


"Fac_Condi t ion" 


cells(3-. 


Ifl) 


•Value = 


"Competition" 


cel Is (3 T 


n) 


•Value = 


"Fac_Ueekend_Use" 


ce 1 1 s ( 3 T 


2D) 


•Value = 


"Fac_Back 1 ogd_Mai nt" 


ce 1 1 s ( 3 T 


21) 


•Value = 


"Area_Loss_Rate" 



DoEvents 



i = D To 


iFacIndex 






j = i + M 










• ce 1 1 s ( j T 


1) . 


Value = 


8 aneasures(i) .FacID 


• ce 1 1 s ( j T 


2) . 


Value = 


aMeasures ( i ) • 


To tal Avai 1 C 1 os 


• ce 1 1 s ( j T 


3) . 


Value = 


aMeasures ( i ) • 


MOSAvailClos 


• ce 1 1 s ( j T 


M) . 


Value = 


aMeasures ( i ) • 


IRR 


• cel 1 s ( j T 


5) . 


Value = 


aMeasures ( i ) • 


IRR_M0S 


• ce 1 1 s ( j T 


b) . 


Value = 


aMeasures ( i ) • 


FacAge 


• ce 1 1 s ( j T 


7) . 


Value = 


"'" & aMeasures ( i ). FacOwned 


• ce 1 1 s ( j T 


fl) . 


Value = 


aMeasures ( i ) • 


Operat ingCost 


• ce 1 1 s ( j T 


T) . 


Value = 


aMeasures ( i ) • 


DistToAMSA 


• ce 1 1 s ( j T 


ID) 


• Value 


= aMeasures(i) 


•DistToECS 


• ce 1 1 s ( j T 


11) 


• Value 


= aMeasures(i) 


• AreaXf erRate 


• ce 1 1 s ( j T 


12) 


• Value 


= aMeasures(i) 


• A vgAreaMan 


• ce 1 1 s ( j T 


13) 


• Value 


= aMeasures(i) 


• AreaOri 1 1 Attend 


• ce 1 1 s ( j T 


IM) 


• Value 


= aMeasures(i) 


• DistT oRecrui t 


• ce 1 1 s ( j T 


15) 


• Value 


= aMeasures(i) 


• Recru i tMarket 


• ce 1 1 s ( j T 


lb) 


• Value 


= aMeasures(i) 


• Reassignments 


• ce 1 1 s ( j T 


17) 


• Value 


= & aMeasures ( i ). FacCond 


. cel Is ( j T 


Ifl) 


•Value 


= aMeasures(i) 


• Competition 


• ce 1 1 s ( j T 


n) 


• Value 


= aMeasures(i) 


• FacUkndUsed 



235 



• cellsCjT EO). Value = afleasures ( i ) . FacBacklogdflaint 
.cellsCjT El). Value = afleasures ( i ) . AreaLossRate 

DoE vents 
Next i 

.cellsCMi 1). Value = "^MOVING UNIT" 

End Uith 

cFilePath = App.Path & FILE_Excel 
SendKeys ">cFA"t True 
SendKeys cFilePathn True 

SendKeys "’/Jt"! True 

SendKeys "IdownMdown} -Cdownl" n True 
SendKeys "^CS"! True 
SendKeys True 

If Not objExcel Is Nothing Then 

objExcel.ActivebJorkBook. Close False 
End If 

objExcel . (3ui t 
Set objExcel = Nothing 
End If 

Screen . riousePoi nter = vbDefault 
Exit Sub 

EH_Ex cel Measures : 

Call 0utputERR0R_L0G 
Set objlilorkSht = Nothing 
End Sub 

Public Sub ResetLDUob ject ( ) 

cProcName = "RESET_LDU_OB JECT" 

If Verif yLDUob jectConnection ( APIf ailedhSG) Then 
SendKeys ")cFN"t True 
SendKeys "^CN"! True 
DoE vents 
End If 
End Sub 

Public Sub ImportLDUdata ( ) 

Dim cFilePath As String 
Dim iLDU_hUnd As Long 

If bLDUactive Then 

VerifyLDUobjectConnection (APIfailedflSG) 

'Load LDU Template File 

cFilePath = App.Path & FILE_LDU_Template 
SendKeys ")cF0"n True 
SendKeys cFilePathi True 
SendKeys "lENTERMENTERI" ^ True 
DoE vents 

'Import Excel Tab delimited file 
cFilePath = App.Path & FILE_LDU_Exce 1 
SendKeys ")CFI"i True 

SendKeys "-CtabMtabMdownMtabMdownMdownMdownMdown}-"! 
SendKeys cFilePathn True 
SendKeys Y>'SXN*/.0" True 
DoE vents 

Call SendCommentsLDU 

'Save Temp file of Imported measure comparisions 
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cFilePath = App.Path S; FILE_LDU_De f au 1 tSave 
SendKeys True 

SendKeys cFilePathn True 
SendKeys True 

DoE vents 
End If 
End Sub 

Public Sub SendCommentsLDU ( ) 

Dim rsFaci 1 ityinf o As Recordset 

Dim i As Byte 

Dim j As Byte 

Dim cFacID As String * 5 

Dim cCity As String 

Dim estate As String * E 

On Error GoTo EH_Comment 

Set rsFaci 1 ityinf o = db Acropo 1 i s . OpenRecordse t ( Tbl_Val idat eUn i t dbOpenTablei 
dbReadOnl y ) 

With rsFaci 1 i tyinfo 
.Index = "FACID'’ 

Fori=0ToM 

.Seek ” = aFacID(i) 

If Not -Noriatch Then 
cFacID = !Fac„ID 
cCity = !City 
estate = IState 

'Send location information to LDli) 

SendKeys True 

For j = D To i 

SendKeys ”-Cdown>"n True 
Next j 

SendKeys ”~ITabMTabMTab }" t True 
SendKeys cFacIDi True 
SendKeys '’-"n True 

SendKeys cCity 8 "n ”8 cStatei True 
SendKeys ”-CtabMtab>'-” 

End If 
Next i 
End Uith 

Set rsFaci 1 ityinf o = Nothing 

Exit Sub 

EH_Comment : 

Exit Sub 
End Sub 

Public Sub ViewLDUmatrix ( ) 

Dim iLDU_hUnd As Long 



If bLDUactive Then 

VerifyLDUobjectConnection (APIfailedflSG) 

DoE vent s 

SendKeys True 

End If 
End Sub 

Public Sub Ac ti vateLDUReports ( ) 

'Print ARIES Model Hierarchy w/ Global weights 
SendKeys ">CUE”7 True 
SendKeys "^H-CdownlG” i True 
Call T i meDe lay ( T ime $ () 1 E) 

SendKeys ”>:FP"n True 

Call TimeDelay (Time$ ( ) T E) ' E second delay 
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SendKeys True 

Call T imeDe lay ( Time$ ( ) T 13) '13 Second delay 

'Print ARIES Model Stacked bar ranking 
SendKeys "/CSB"t True 

Call TimeDe lay ( Time$ ( ) n E) 'E Second delay 

SendKeys True 

SendKeys True 

Call TimeDe lay ( Time$ ( ) T 5) '5 Second delay 

'Print ARIES Model Comment Summary 
SendKeys '’/CR00-"n True 
SendKeys True 

Call T i meDe lay ( Ti me^ ( ) T S) '5 Second delay 

'Change Printer Setup for Landscape Mode 
SendKeys "*/CFR^L-"t True 

Call T imeDe lay ( Time ^ ( ) 1 1) '1 Second delay 

'Print ARIES Model Preference Set Summary 
SendKeys ”/:SP-"t True 
SendKeys "/CFP"t True 

Call T imeDe lay ( Time$ ( ) -I 5) '5 Second delay 

'Print ARIES Model Ranking results matrix 
SendKeys ")CSMM~”-. True 
SendKeys ">CFP"i True 

Call T imeDe lay ( Time$ ( ) T 5) '5 Second delay 

'Change Printer Setup for Portrait Mode 
SendKeys ")CFR^R~"t True 

Call TimeDe lay ( Time$ ( ) T 1) '1 Second delay 

End Sub 
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Module 6. OLE OBJECT CLASS DEFINITION 



Purpose: An object class description necessary for communicating with the integrated 

Mapinfo component. 

Source Type: Visual Basic for Applications 



Source File: OLE CALLBACK.CLS 



Code Listing: 



VERSION l.Q CLASS 
BEGIN 

MultiUse = -1 'True 

END 

Attribute VB_Name = "clsOLECal 1 back” 

Attribute VB_Creatable = False 
Attribute VB_Exposed = True 
Option Explicit 

Private Function GetFi e Id ( By Va 1 theStr As String-i ByVal delimiter As Stringi 
ByVal whichField As Integer) As String 
cProcName = ”FUNC : GET^FIELD” 

Dim i As Integer 
Dim startPos As Integer 
Dim argCount As Integer 
Dim tmpStrn result As String 

if the input string was nulli or they asked for a field ^ less than It 
return an empty string as the result 
If Len(theStr) = □ Or whichField < 1 Then 
GetField = ”” 

Exit Function 
End If 

loop through til we get the field we want- If the string contains fewer 
fields than the field number requested! a zero-length string is returned- 
argCount = D 
tmpStr = theStr 

Do 

argCount = argCount + 1 

result = Lef t$ ( tmpStr T InStr ( tmpStr t delimiter) - 1) 
tmpStr = riid$ ( tmpStr ! InS tr ( tmpS tr t delimiter) + 1) 

Loop While InStr ( tmpStr t delimiter) > □ And argCount < whichField 

if we dropped out of the while loop because InStrC) returned Ot and 

we haven't gotten to the desired field yeti take one more step in case 

we are actually looking for the last field in the string- 
If argCount < whichField Then 

argCount = argCount + 1 

result = tmpStr 
End If 

'* if we found our fieldi argCount will equal whichField- return the 
'* result string! otherwise-i return a zero-length string 
If argCount = whichField Then 
GetField = result 
Else 
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GetField = "" 

End If 

End Function 

' ProcGssInf oToo IButton 

' This method is called when the custom tools defined in flaplnfo 

' in the "Ini t ial izeflaplnf oConnection" are used in the map window. 

' This method determines which tool was used ( a point select tooli 

' and a rectangle select tool )i and performs the appropriate action 

Public Sub Processinf oToolButton (ByVal Commandinf oText As String) 
cProcName = "PR0CESS_T00L_BUTT0N" 

Dim iSelectedButton As Integer 
Dim fXpt As Double 
Dim fYpt As Double 
Dim nHits As Long 

'Verify that the Windows Message came from Maplnfo 

'If it did come from flaplnfoi strip off the "MI:" prefix: 

If Le ft $( Commandinf oText 1 3) = "MI:" Then 

Commandinf oText = Mid$ ( Commandinf oText-i Mt Ti‘=n) 

Else 

Exit Sub 

End If 'Determine which Tool Selected 

iSelectedButton = CInt (GetFieldC Commandinf oText-. CMD_INF0_T00LBTN ) ) 

Select Case iSelectedButton 
Case SOI 'info tool 

fXpt = CDbl (GetField ( CommandInfoText CMD_INF0_X)) '* get x 

and y 

fYpt = CDbl ( GetF ie Id ( Commandinf oText -I "t"-. CMD_INF0_Y)) '* from 

Commandinf o 

Call DisplaySelectedFaci 1 i ty ( f Xpti fYpt) 

End Select 

End Sub 

Private Sub D i sp 1 aySe 1 ec tedFac i 1 i ty ( By Va 1 fXpt As Double-. ByVal fYpt As 
Doub 1 e ) 

cProcName = "DISPLAY_SELECTED_FACILITY" 

Dim nHits As Long 
Dim iRecNum As Long 
Dim i As Long 

Dim tMapHitsC) As Inf oToo l_Type 
Dim tFac i 1 i tyinf o As Faci 1 i ty_Type 
Dim rsGeoREFdata As Recordset 

'Get number of "Hits" using the MapBasic function -CSearchPoint ( ) } 

'FORMAT: nHits = SearchPointC maplilinlD-. x-. y ) 

nHits = CLng (ob jGeoSelect -Eval ("SearchPoint (" & iMapInf oUinID a a fXpt a 

a fYpt a ")")) 

Set rsGeoREFdata = dbAcropol is . OpenRecordset (Tbl_Val idateUnit-. dbOpenTabl e -. 
dbReadOnly ) 

rsGeoREFdata . Index = "FACID" 

With frmAriesMain 

!txtPropFacID. Clear 
!trvGISData.Nodes.Clear 
i PropFacIDct r = D 

If Not (nHits = D) Then 'there were hits: scan using "Searchinfo" 

ReDim tMapH i ts ( nHi t s ) 
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For i = 1 To nHits 

triapHits ( i ) . riapTable = ob jGeoSe lect . Eval ( "Searchinf o ( ” & i & "i” S; 
SEARCH_INFO_TABLE & ")") 

iRecNum = CLng ( ob jGeoSe lect . Eval ( "Searchinf o ( " & i & 8; 

SEARCH_INF0_R0U & ")") ) 

ob jGeoSe 1 ect . Do "Fetch Rec " & iRecNum & " from " & 
tMapHits(i) .flapTable 

thapHits ( i ) . GeoFacID = ob jGeoSelect -Eval ( tdapHits ( i ) • HapTable a 

" -coll") 



ItxtPropFacID.AddItem tdapH i ts (i) -GeoFacID 
Next i 

'Get a Display Proposed Facility Data 
tFaci 1 i tyinf o • FacID = ! txtPropFacID . List (0 ) 

Call GetPropFacilityInfo(tFacilityInfo-» rsGeoREFdata ) 

Call DisplayPropFacilityInfo ( tFaci li tyinf o) 

Call DisplayTreeViewInf o ( tHapHits ( ) T nHits) 

If (nHits = 1) Then 

! spinFacIDbtn .Visible = False 
Else 

! sp inFacIDbtn . Vi sible = True 
End If 

Else 'No Facility Selected - Clear all Proposed Facility fields 

IcboUIC. Clear 
! IstbxUnitName- Clear 

! IstbxUnitName. Additem "** NO FACILITY SELECTED 
!txtCity = vbNullString 
ItxtState = VbNullString 
ItxtZipCode = vbNullString 
End If 
End Uith 
End Sub 

Sets ta tusTex t 

' This is a standard method that haplnfo looks for in its Callback 

' object. If Maplnfo finds this method in the Callback objectn it 

' will get called automat ical ly every time the text in flaplnfo's 

' status bar text changes. The string passed in is a tab-delimited 

' string containing each of the status bar "Fields"*) i.e. - the 

' first field is the zoom-i scale-) or cursor location-) the second field 

' is the editable layer-) etc. 

*********************************************************************** 

Public Sub SetStatusText (ByVal cStatusText As String) 
cProcName = "SET_STATUS_TEXT" 

Dim cNewText As String 

cNewText = GetField ( cStatusText -> vbTab-> 1) '* get first field in tab- 

delimited string 

If Not (cNewText = "") Then 

f rmAri esflain ! Ari esStatusBar . Panels ( M ). Text = cNewText 
End If 

End Sub 
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Module 7. MAPBASIC PUBLIC DECLARATIONS 



Purpose: A library module that initializes all public variables and constants for 

communicating with the integrated mapping component. 

Source Type: Visual Basic for Applications 

Source File: libMAPBASIC.BAS 

Code Listing: 



Attribute VB_Name = ”1 ibHAPB ASIC" 



flaplnfo version M-D - System defines 



This file contains defines useful when programming in the MapBasic 
language- There are three versions of this file: 
n A PB ASIC - DEF - dapBasic syntax 
dAPBASIC-BAS - Visual Basic syntax 
dAPBASIC-H - C/C++ syntax 



The defines in this file are organized into the following sections: 
General Purpose defines: 

Hacrosi Logical constants! Angle conversion! Colors 
ButtonPadInf 0 ( ) defines 
ColumnInfoC) defines 
Commandinf 0 ( ) defines 
FileAttrC) defines 
IntersectNodes ( ) parameters 
LayerInfoC) defines 
dapperlnfoC) defines 

denul teminf oBylD ( ) and llenultemlnf oByHandl er ( ) defines 

Ob jectGeography ( ) defines 

ObjectInfoC) defines 

SearchInfoC) defines 

Se lectioninf o ( ) defines 

Server statement and function defines 

Str ingCompare ( ) return values 

StyleAttrC) defines 

SystemInfoC) defines 

TableInfoC) defines 

UindowInfoC) defines 

Abbreviated list of error codes 

Backward Compatibility defines 

This file is converted into HAPBASIC-H by doing the following: 

- concatenate flAPBASIC-DEF and HENU-DEF into flAPBASIC-H 

- search & replace at begining of a line with "//" 

- search & replace "Define" at begining of a line with "♦♦define" 

“ delete the following sections: 

* General Purpose defines: Macros! Logical Constants! Angle 
Con vers i ons 

* Abbreviated list of error codes 

* Backward Compatibility defines 

* Menu constants whose names have changed 

t Obsolete menu items 



This file is converted into MAPBASIC-BAS by doing the following: 

- concatenate MAPBASIC-DEF and MENU-DEF into MAPBASIC-BAS 

- search & replace "Define <name>" with "Global Const <name> =" 

e-g. "<Define -C[!-z3 + > +CC!-zJ>" with "Global Const \D = \1" using Brief 
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“ delete the following sections: 

* General Purpose defines: flacrosT Logical Constantsi Angle 
Conversions 

* Abbreviated list of error codes 

* Backward Compatibility defines 

* Menu constants whose names have changed 

* Obsolete menu items 



General Purpose defines 



Colors 



I 

Global 


Const 


BLACK = □ 






Global 


Const 


WHITE = lb?77BlS 






Global 


Const 


RED = IbVlltiflD 






Global 


Const 


GREEN = LSBaO 






G1 obal 


Const 


BLUE = ESS 






Global 


Const 


CYAN = t.553S 






Global 


Const 


flAGENTA = lt,711'^3S 






G1 obal 


Const 


YELLOW = lb77b‘1t.Q 






' Butto 


nPadIn 


fo() defines 


;;;;; 


II 

II 

II 

II 

II 

II 

II 

II 

II 

II 

II 

II 

II 

II 

II 

II 


Global 


Const 


BTNPAD INF0_FL0ATING = 1 






G1 obal 


Const 


BTNPAD INFO UIDTH = E 






G1 obal 


Const 


BTNPAD_INFO_NBTNS = 3 






Global 


Const 


BTNPAD_INFO_X = M 






G1 obal 


Const 


BTNPAD_INFO_Y = 5 






Global 


Const 


BTNPAD_INFO_UINID = L 






' Colum 


ininf 0 ( 


) defines 


;;;;; 


II 1 

II 1 

II 1 

II 1 

II 1 

II 1 

II 1 

II 1 

II 1 

II 1 

II 1 

II 1 

II 1 

II 1 

II 1 

II 1 


Global 


Cons t 


COL INFO_NAriE = 1 






G 1 obal 


Const 


C 0 L_INF 0 _NUn = E 






Global 


Const 


C0L_INF0_TYPE = 3 






G1 obal 


Const 


COL INFO UIDTH = M 






Global 


Const 


COL_INFO_DECPLACES = S 






G1 obal 


Const 


COL INFO_INDEXED = t> 






G 1 obal 

1 


Const 


COL_INFO_EDITABLE = 7 






* Column type 


1 definesT returned by Columninf o ( <col_ref > i 


C0L_ 


INF0_TYPE) 


Global 


Const 


COL TYPE_CHAR = 1 






Global 


Const 


COL TYPE_DECiriAL = E 






Global 


Const 


COL_TYPE_INTEGER = 3 






Global 


Const 


C0L_TYPE_Sf1ALLINT = M 






G1 oba 1 


Const 


COL TYPE_DATE = S 






Global 


Const 


COL TYPE_LOGICAL = L 






Global 


Const 


COL_TYPE_GRAPHIC = 7 






Global 


Const 


C0L_TYPE_FL0AT = fl 






II U 1 

II u- 1 
II C 1 
II M 1 
II ID 1 
11 C 1 

11 m 1 

11 E 1 
II E 1 
II O 1 
II CJ 1 
II 1 


I ( ) defines 


II 1 

II 1 

II 1 

II 1 

II 1 


II 1 

II 1 

II 1 

II 1 

II 1 

II 1 

II 1 

II 1 

II 1 

II 1 

II 1 

II 1 

II 1 

II 1 

II 1 

II 1 


Global 


Const 


CflD INF0_X = 1 






Global 


Const 


Cf1D_INF0_Y = E 






Global 


Const 


Cf1D_INF0_SHIFT = 3 






G1 obal 


Const 


CMD_INFO_CTRL = M 






Global 


Const 


CnD_INFO_XE = S 






Global 


Const 


CriD_INFO__YE = t. 






Global 


Const 


CflD INF0_T00LBTN = 7 






Global 


Const 


CnD_INF 0 _f 1 ENUITEn = 6 






Global 


Const 


CriD_INFO_UIN = 1 






G lobal 


Const 


CnD_INFO_SELTYPE = 1 
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Global 


Const 


Global 


Const 


Global 


Const 


Global 


Const 


Global 


Const 


Global 


Const 


Global 


Const 


Global 


Const 


Global 


Const 


Global 


Const 


Global 


Const 



CnD_INFO_ROli)ID = E 
CnD__INFO_INTERRUPT = 3 
CriD_INFO_STATUS = 1 
CnD_INFO_nSG = IDDD 
CnD_INFO_DLG_OK = 1 
CnD_INFO_DLG_DBL = 1 
CnD_INFO_FIND_RC = 3 
CnD_INFO_FIND_ROUID = M 
CnD_INFO_XCnD = 1 
CnD__INFO_CUSTOn_OBJ = 1 
CnD_INFO_TASK_SUITCH = 1 



' Task SwitchT returnGcl by Commandinf o ( CriD_INFO_T ASK_SUITCH ) 



Global Const Sli)ITCHING_OUT_OF_nAPINFO = D 
Global Const SUITCHING_INTO_nAPINFO = 1 



' FilGAttr() defines 

Global Const FILE_ATTR_nODE = 1 
Global Const FILE_ATTR_FILESIZE = E 



' File Access modesi returned by F i 1 e Attr ( <f i le__id> t FILE_ATTR_f10DE ) 



Global Const nODE_INPUT = 0 
Global Const nODE_OUTPUT = 1 

Global Const MODE_APPEND = E 

Global Const M0DE_RAND0n = 3 

Global Const nODE_BINARY = M 



' IntersectNodes ( ob jli objEn mode) parameters 

Global Const INCL_CROSSINGS = 1 
Global Const INCL_COnnON = b 
Global Const INCL_ALL = 7 



' Layerinf o ( ) 

Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 



defines 

LAYER_INFO_NAME = 1 
LAYER_INFO_EDITABLE = E 
LAYER_INFO_SELECTABLE = 3 
LAYER_INF0_Z00n_LAYERED = M 
LAYER_INF0_Z00n_niN = 5 
LAYER_INF0_Z00n__nAX = b 
LAYER_INFO_COSnETIC = 7 
LAYER__INFO_PATH = fl 
LAYER_INFO_DISPLAY = T 
LAYER_INFO_OVR_LINE = ID 
LAYER_INFO_OVR_PEN = 11 
LAYER_INFO_OVR_BRUSH = IE 
LAYER_INF0_0VR_SYnB0L = 13 
LAYER_INF0_0VR_F0NT = IM 
LAYER_INFO_LBL_EXPR = IS 
LAYER_INFO_LBL_LT = It, 
LAYER_INFO_LBL_CURFONT = 17 
LAYER_INFO_LBL_FONT = Ifi 
LAYER_INFO_LBL_PARALLEL = IT 
LAYER_INFO_LBL_POS = ED 
LAYER_INFO_ARROUS = El 
LAYER_INFO_NODES = EE 
LAYER_INFO_CENTROIDS = E3 
LAYER_INFO_TYPE = EM 
LAYER_INFO_LBL_VISIBILITY = ES 
LAYER_INF0_LBL_Z00n_niN = Eb 
LAYER_INFO_LBL_ZOOn_nAX = E7 
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Global Const L A YER_INFO_LBL_AUTODISPLA Y = Efl 
Global Const LA YER_INFO_LBL_OVERL AP = ET 
Global Const L AYER_INFO_LBL_DUPLICATES = 3D 
Global Const L A YER_INFO_LBL_OFFSET = 31 
Global Const L A YER_INFO_LBL_nAX = 3E 



' Display flodesi returned by LayerInfoC) for L A YER_INFO_DISPL AY 



Global Const L A YER_INFO_DISPLAY_OFF = 0 
Global Const L AYER_INFO_DISPLA Y_GR APHIC = 1 
Global Const L AYER_INFO_DISPLA Y_GL0BAL = E 
Global Const L A YER_INFO_DISPLAY_V ALUE = 3 



' Label Linetypesi returned by LayerInfoC) for LAYER_INFO_LBL_LT 



Global Const LA YER_INFO_LBL_LT_NONE = 0 
Global Const L AYER_INFO_LBL_LT_SinPLE = 1 
Global Const L A YER_INFO_LBL_LT_ARROU = E 



' Label Positions-, returned by LayerInfoC) for LA YER_INF0_LBL_P0S 



Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 



Const LAYER_INFO_LBL_POS_CC 
Const LAYER_INFO_LBL_POS_TL 
Const LAYER_INFO_LBL_POS_TC 
Const LAYER_INFO_LBL_POS_TR 
Const LAYER_INFO_LBL_P0S_CL 
Const LAYER_INFO_LBL_POS_CR 
Const LAYER_INFO_LBL_POS_BL 
Const LAYER_INFO_LBL_POS_BC 
Const LAYER_INFO_LBL_POSJR 



0 

1 

E 

3 

M 

S 

L 

7 

fi 



' Layer Types-, returned by LayerInfoC) for L A YER_INF0_T YPE 



Global Const L A YER_INFO_TYPE_NORMAL = 0 
Global Const L AYER_INFO_TYPE_COSnETIC = 1 
Global Const L AYER_INFO_TYPE_iriAGE = E 
Global Const L A YER_INFO_TYPE_THEnATIC = 3 



' Label visibility modes-, returned by LayerInfoC) for L A YER_INFO_LBL_VISIBILITY 



Global Const L A YER_INFO_LBL_VIS_OFF = 1 
Global Const L AYER_INF0_LBL_VIS_Z00n = E 
Global Const L AYER_INFO_LBL_VIS_ON = 3 



' riapperlnfoC) defines 



Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 



Const nAPPER_INF0_Z00n = 1 
Const nAPPER_INFO_SCALE = E 
Const riAPPER_INFO_CENTERX = 3 
Const nAPPER_INFO_CENTERY = M 
Const riAPPER_INFO_niNX = 5 
Const nAPPER_INFO_niNY = b 
Const nAPPER_INFO_nAXX = 7 
Const nAPPER_INFO_riAXY = 8 
Const nAPPER_INFO_LAYERS = T 
Const nAPPER_INFO_EDIT_LAYER = ID 
Const nAPPER_INFO_XYUNITS = 11 
Const nAPPER_INFO_DISTUNITS = IE 
Const nAPPER_INFO_AREAUNITS = 13 
Const MAPPER_INFO_SCROLLBARS = IM 
Const nAPPER_INFO_DISPLAY = IS 
Const nAPPER_INFO_NUn_THEnATIC = lb 
Const nAPPER_INFO_COORDSYS_CLAUSE = 17 
Const MAPPER_INFO_COORDSYS_NAnE = 18 
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Display flodesT returned by MapperlnfoC) for f1APPER_INF0_DISPLA Y 






_INFO_ENABLED = 1 
,INFO_CHECKED = B 
INFO^CHECKABLE = 3 
.INFO.SHOUHIDEABLE = M 
.INFO.ACCELERATOR = S 
.INFO.TEXT = t, 
_INFO_HELPnSG = 7 
INFO_HANDLER = fi 
INF0_ID = ^ 



Global 


Const 


G 1 oba 1 


Const 


Global 


Const 


il C i 
II M 1 
II E 1 
II OJ 1 
II 4-) 1 
II HH 1 
II D 1 
II C 1 
II 01 1 
II 2Z 1 
II 1 


Global 


Const 


Global 


Const 


Global 


Const 


Global 


Const 


Global 


Const 


Global 


Const 


G 1 obal 


Const 


G 1 obal 


Const 


Global 


Const 


' ObjectGeogi 


G 1 obal 


Const 


Global 


Const 


Global 


Const 


Global 


Const 


Global 


Const 


Global 


Const 


Global 


Const 


Global 


Const 


Global 


Const 


Global 


Const 


Global 


Const 


Global 


Const 


Global 


Const 


Global 


Const 


Global 


Const 


Global 

f 


Const 


' Objectinfo 


Global 


Const 


Global 


Const 


Global 


Const 


Global 


Const 


Global 


Const 


Global 


Const 


Global 


Const 


Global 


Const 


Global 


Const 


Global 


Const 


Global 


Const 


G 1 obal 


Const 


Global 


Const 


G 1 oba 1 


Const 



0BJ_GE0_ 

0BJ_GE0^ 

0BJ_GE0. 

0BJ_GE0_ 

0BJ_GE0^ 

0BJ_GE0_ 

0BJ_GE0_ 

OBJ^GEO^ 

0BJ_GE0_ 

OBJ^GEO^ 

OBJ.GEO^ 

0BJ_GE0 

0BJ_GE0^ 

0BJ_GE0_ 

0BJ_GE0_ 

OBJ GEO^ 



niNX = X 
LINEBEGX = 1 
POINTX = 1 
niNY = E 
LINEBEGY = E 
POINTY = E 
riAXX = 3 
LINEENDX = 3 
HAXY = M 
LINEENDY = M 
ARCBEGANGLE = 5 
TEXTLINEX = 5 
ROUNDRADIUS = S 
ARCENDANGLE = b 
TEXTLINEY = L 
TEXTANGLE = 7 



0BJ_INF0. 

OBJ_INFO 

OBJ_INFO_ 

OBJ_INFO. 

OBJ_INFO_ 

OBJ_INFO. 

OBJ.INFO. 

OBJ_INFO_ 

OBJ.INFO. 

OBJ^INFO. 

OBJ.INFO. 

OBJ.INFO. 

OBJ.INFO. 

OBJ_INFO. 



TYPE = 1 
PEN = E 
SYMBOL = E 
TEXTFONT = E 
BRUSH = 3 
NPNTS = ED 
TEXTSTRING = 3 
SMOOTH = M 
FRAMEUIN = ^ 
NPOLYGONS = EX 
TEXTSPACING = M 
TEXTJUSTIFY = 5 
FRAMETITLE = L 
TEXTARROU = b 



' Object typesn returned by Ob jectinf o ( <ob j> OB J_INF0_T YPE ) 



G 1 obal 


Const 


Global 


Const 


G 1 oba 1 


Const 


Global 


Const 


G 1 obal 


Const 


Global 


Const 


Global 


Const 


Global 


Const 



OBJ_TYPE_ARC = 1 
OBJ_TYPE_ELLIPSE = E 
OBJ_TYPE_LINE = 3 
OBJ_TYPE_PLINE = M 
OBJ_TYPE_POINT = 5 
OBJ_TYPE_FRAME = b 
OBJ_TYPE_REGION = 7 
OBJ_TYPE_RECT = 6 
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Global Const OB J_TYPE_ROUNDRECT = T 
Global Const OB J_TYPE_TEXT = ID 



' SearchlnfoC) defines 



Global Const SEARCH_INFO_TABLE = 1 
Global Const SEARCH_INF0_R0U = E 



' Se lect i oninf o ( ) defines 



Global Const SEL_INFO_TABLEN AME = 1 

Global Const SEL_INFO_SELN AHE = E 

Global Const SEL_INF0_NR0blS = 3 



Server statement and function defines 



Return Codes 



Global Const SRV^SUCCESS = □ 

Global Const SR V_SUCCESS_UITH_INF0 = 1 
Global Const SRV_ERR0R = -1 
Global Const SRV_INV ALID_HANDLE = -E 
Global Const SR V_NEED_D ATA = 

Global Const SRV_NO_nORE_D ATA = IDD 



' Special values for the status associated with a fetched value 



Global Const SR V_NULL_DATA = -1 
Global Const SR V_TRUNCATED_DAT A = -E 



' Server_ColumnInf o ( ) Attr defines 



Global Const SRV_C0L_INF0_N AME = 1 
Global Const SR V_C0L_INF0_T YPE = E 
Global Const SR V_C0L_INF0_UIDTH = 3 
Global Const SRV_COL_INFO_PRECISION = M 
Global Const SR V_C0L_INF0_SCALE = S 
Global Const SR V_C0L_INF0_V ALUE = b 
Global Const SR V_C0L_INF0_ST ATUS = 7 



' Column types*! returned by Server__ColumnInf o (<stmt>*i<colno>TSRV_COL_INFO_TYPE) 



Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 



Const SRV_COL_TYPE_NONE = □ 

Const SRV_COL_TYPE_CHAR = 1 
Const SRV_C0L_TYPE_DECIf1AL = E 
Const SRV__COL_TYPE_INTEGER = 3 
Const SRV_COL_TYPE_SnALLINT = M 
Const SRV_COL_TYPE_DATE = 5 
Const SRV_COL_TYPE_LOGICAL = b 
Const SRV_COL_TYPE_FLOAT = fi 
Const SRV_COL_TYPE_FIXED_LEN_STRING 
Const SRV_COL_TYPE_BIN_STRING = 17 



lb 



' Server_Dr i ver Inf o ( ) Attr defines 



Global Const SR V_DRV_INFO_N AHE = 1 
Global Const SRV_DRV_INFO_N AME_LIST = E 
Global Const SR V_DRV_DATA_SOURCE = 3 



' Fetch Directions used by Server_Fe tch ( ) 
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Global Const SR V_FETCH_NEXT = -1 
Global Const SR V_FETCH_PREV = -E 
Global Const SR V_FETCH_FIRST = -3 
Global Const SRV_FETCH_L AST = -M 



' StringCompare ( <str_l> T <str_E>) return values 

Global Const STR_LT = -1 

Global Const STR_GT = 1 

Global Const STR_E(3 = 0 



' StyleAttr() 

Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 



defines 

PEN_liJIDTH = 1 
PEN_PATTERN = E 
PEN^COLOR = 4 
BRUSH^PATTERN = 1 
BRUSH_FORECOLOR = E 
BRUSH_BACKCOLOR = 3 
F0NT_NAHE = 1 
FONT_STYLE = E 
FONT_POINTSIZE = 3 
FONT^FORECOLOR = M 
F0NT_BACKC0L0R = S 
SYnB0L_C0DE = 1 
SYnBOL_COLOR = E 
SYnBOL_POINTSIZE = 3 
SYMBOL_ANGLE = M 
SYnBOL_FONT_NAHE = 5 
SYnBOL_FONT_STYLE = t, 
SYMBOL.KIND = 7 

SYnBOL_cusTon_NAnE = a 

SYnBOL_CUSTOn_STYLE = 1 



' Symbol kinds returned by S ty 1 eAttr ( <symbol> t SYMB0L_KIND) 



Global Const S YHBOL^KIND.VECTOR = 1 

Global Const S YriBOL_KIND_FONT = E 

Global Const S YnBOL_KIND_CUSTOn = 3 



' SystemInfo() defines 



Global 
Global 
Globa 1 
Global 
Global 
Global 
Global 
Global 
Global 
Global 
Global 
Global 
Global 
Global 
Global 



Const SYS_INFO_PLATFORH = 1 
Const SYS_INFO_APPVERSION = E 
Const SYS_INFO_niVERSION = 3 
Const SYS_INFO_RUNTinE = M 
Const SYS_INFO_CHARSET = 5 
Const SYS_INFO_COPYPROTECTED = t> 
Const SYS_INFO_APPLICATIONUND = 7 
Const SYS_INFO_DDESTATUS = 6 
Const SYS_INF0_nAPINF01iJND = T 
Const SYS_INFO_NUnBER_FORMAT = ID 
Const SYS_INFO_DATE_FORnAT = 11 
Const SYS_INFO_DIG_INSTALLED = IE 
Const SYS_INFO_DIG_nODE = 13 
Const SYS_INFO_niPLATFORn = IM 
Const SYS_INFO_nDICLIENTUND = 15 



' Platform-i returned by Systeminf o (SYS_INFO_PL ATFORfl) 



Global Const PL ATFORn_SPECI AL = □ 
Global Const PL ATFORMJIN = 1 

Global Const PLATFORn_nAC = E 

Global Const PL ATFORn_nOTIF = 3 

Global Const PLATFORH^Xll = M 
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Global Const PLATF0RN_X0L = 5 



' Vension-i returned by Systeminf o (SYS_INF0_I1IPL ATFORM ) 



Global Const HIPL ATFORM^SPECI AL = □ 
Global Const I1IPL ATFORMJINlt, = 1 
Global Const niPLATF0RrUIN32 = P 
Global Const MIPL ATF0Rf1_P0UERnAC = 3 
Global Const I1IPL ATF0Rn_nACt3flK = M 
Global Const HIPL ATF0RI1_HP = 5 
Global Const HIPL ATF0RI1_SUN = L 



' TableInfoC) defines 



Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 



Const TAB_INF0_NAf1E = 1 
Const TAB_INF0_NUf1 = P 
Const TAB_INFO_TYPE = 3 
Const TAB_INF0_NC0LS = M 
Const TAB_INFOJAPPABLE = 5 
Const TAB_INFO_READONLY = b 
Const TAB_INFO_TEnP = 7 
Const TAB_INF0_NR0US = fi 
Const TAB_INFO_EDITED = T 
Const TAB_INFO_FASTEDIT = ID 
Const TAB_INF0_UND0 = 11 
Const TAB_INFO_nAPPABLE_TABLE = IP 
Const TAB_INFO_USERMAP = 13 
Const TAB_INFO_USERBROUSE = IM 
Const TAB_INFO_USERCLOSE = 15 
Const TAB_INFO_USEREDITABLE = lb 
Const TAB_INFO_USERREnOVEriAP = 17 
Const TAB_INF0_USERDISPLAYf1AP = 16 
Const TAB_INFO_TABFILE = IT 
Const TAB_INFO_niNX = PO 
Const TAB_INFO_niNY = PI 
Const TAB_INFO_riAXX = PP 
Const TAB_INF0_f1AXY = P3 
Const TAB_INFO_SEAnLESS = PM 
Const TAB_INFO_COORDSYS_niNX = P5 
Const TAB_INFO_COORDSYS_niNY = Pb 
Const TAB_INFO_COORDSYS_nAXX = P7 
Const TAB_INFO_COORDSYS_nAXY = P6 
Const TAB_INFO_COORDSYS_CLAUSE = PT 
Const TAB_INFO_COORDSYS_NAriE = 30 
Const TAB_INF0_NREFS = 31 



' Table type defines^ returned by Tableinf o (<tab_ref > •» TAB_INF0_TYPE ) 



Global Const T AB_T YPE_BASE = 1 
Global Const T AB_T YPE^RESULT = P 
Global Const TAB_T YPE_VIEU = 3 
Global Const TAB_T YPE_inAGE = M 
Global Const T AB_T YPE_LINKED = 5 



' Uindowinf o ( ) defines 



Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 



Const UIN_INF0_NAnE = 1 
Const UIN_INF0_TYPE = 3 
Const UIN_INFO_bJIDTH = M 
Const UIN_INFO_HEIGHT = 5 
Const UIN_INF0_X = b 
Const UIN_INF0_Y = 7 
Const blIN_INF0_T0Pn0ST = 6 
Const UIN_INF0_STATE = T 
Const lilIN_INFO_TABLE = ID 
Const UIN_INF0_LEGENDS_I1AP 



ID 
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Global Const UIN_INF0_0PEN = 11 
Global Const UIN_INFO_UND = 12 
Global Const UIN_INFO_UINDOUID = 13 
Global Const U IN_INF0_U0RKSP ACE = IM 
Global Const U IN_INFO_CLONEUINDOlil = IS 
Global Const UIN.INFO.SYSnENUCLOSE = lb 
Global Const UIN_INF0_AUT0SCR0LL = 17 



' lilindow typesT returned by U i ndowinf o ( <win_id> t UIN_INF0_TYPE ) 



Global 
Global 
Global 
Global 
G 1 obal 
Global 
Global 
Global 
Global 
Global 
Global 
Global 
Global 



Const UIN_nAPPER = 1 
Const UIN_BROlilSER = 2 
Const UIN_LAYOUT = 3 
Const UIN_GRAPH = M 
Const UIN_BUTTONPAD = IT 
Const UIN_HELP = IDDl 
Const UIN_nAPBASIC = 1DD2 
Const UIN_nESSAGE = 1DD3 
Const UIN_RULER = 1DD7 
Const UIN_INF0 = IDDfi 
Const UIN.LEGEND = IDDT 
Const UIN_STATISTICS = 1010 
Const liJIN.nAPINFO = IDll 



' Version 2 window types no longer used in version 3 or version ^ 
r 



Global Const UIN^TOOLPICKER = IDDM 
Global Const UIN.PENPICKER = IDDS 
Global Const UIN^SYMBOLPICKER = IDDb 



' lilindow statesT returned by U indowinf o ( <win_id> -i lilIN_INFO_STATE ) 



Global Const lilIN_STATE_NORnAL = □ 
Global Const lilIN_STATE_niNiniZED = 1 
Global Const UIN_STATE_nAXiniZED = 2 



* Set Next Document Style defines 

Global Const UIN_STYLE_STANDARD = □ 

Global Const lilIN_STYLE_CHILD = 1 

Global Const UIN_STYLE_POPUP_FULLCAPTION = 2 

Global Const UIN_STYLE_POPUP = 3 



end of NAPBASIC.DEF 



flaplnfo version M-D - Menu Item Definitions 



This file contains defines useful when programming in the MapBasic 
language. The definitions in this file describe the standard Maplnfo 
functionality available via the "Run henu Command" MapBasic statement. 



The defines in this file are organized to match the sequence of 
declarations in the MAPINFOU . MNU filei which in turn reflects the 
organization of the Mapinfo menus and buttonpads* 



File 2 , Send Mail menus 



Global Const M_FILE_NElil = IDl 
Global Const M_FILE_0PEN = 102 
Global Const M_FILE_0PEN_0DBC = lib 
Global Const M_FILE_ADD_UORKSP ACE = IDfi 
Global Const M_FILE_CL0SE = 103 
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Global 


Const 


G1 obal 


Const 


G1 obal 


Const 


Global 


Const 


Global 


Const 


Global 


Const 


Global 


Const 


Global 


Const 


Global 


Const 


Global 


Const 



n_FILE_CLOSE_ALL = IDH 
n_FILE_SAVE = IDS 
n_FILE_SAVE_COPY_AS = IDb 
n_FILE_SAVE_UORKSPACE = 
n_FILE_SAVE_UINDOU_AS = bDS 
n_FILE_REVERT = 1D7 
n_FILE_RUN = IIQ 
n_FILE_PAGE_SETUP = 111 
n_FILE_PRINT = HE 
n_FILE_EXIT = 113 



Global Const n.SENDfl AIL_CURRENTUINDOU = IIM 
Global Const n.SENDflAIL.UORKSP ACE = IIS 



' Edit menu 



Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 



Const n_EDIT_UNDO = EDI 
Const n_EDIT_CUT = EDE 
Const n_EDIT_COPY = ED3 
Const f1_EDIT_PASTE = EDM 
Const n_EDIT_CLEAR = EDS 
Const n_EDIT_CLEAROBJ = EDt 
Const n_EDIT_RESHAPE = ItDl 
Const n_EDIT_NEU_ROU = 7DE 
Const M_EDIT_GETINFO = ED7 



' Objects menu 



Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 



Const n_OBJECTS_SET_TARGET = IblD 
Const n_OBJECTS_CLEAR_TARGET = Ibll 
Const n_0BJECTS_C0f1BINE = IbDS 
Const n_OBJECTS_SPLIT = IblE 
Const n_OBJECTS_ERASE = lbl3 
Const n_OBJECTS_ERASE_OUT = IblM 
Const n_OBJECTS_OVERLAY = IblS 
Const n_OBJECTS_BUFFER = ILQL 
Const n_OBJECTS_SnOOTH = IbDE 
Const n_0BJECTS_UNSn00TH = 1LQ3 
Const n_OBJECTS_CVT_PGON = ltD7 
Const n_OBJECTS_CVT_PLINE = ILDM 



' (3uery menu 



Global Const (1_AN AL YZE_SELECT = 3D1 
Global Const f1_AN AL YZE_S(3L(3UERY = 3DE 
Global Const f1_AN AL YZE_SELECT ALL = 3D3 
Global Const f1_ANALYZE_UNSELECT = 3DM 
Global Const f1_AN ALYZE_FIND = 3DS 
Global Const n_ANALYZE_FIND_SELECTION = 3Db 
Global Const n_ANALYZE_CALC_ST ATISTICS = 3QS 



' Tablei Main tenance -• and Raster menus 



G 1 obal 
G 1 obal 
Global 
Global 
Global 
Global 
Global 



Const n_TABLE_UPDATE_COLUnN = MD5 
Const n_TABLE_APPEND = Mil 
Const n_TABLE_GE0C0DE = MD7 
Const n_TABLE_CREATE_POINTS = MQ8 
Const n_TABLE_f1ERGE_USING_C0LUnN 
Const n_TABLE_IflPORT = MDl 
Const n_TABLE_EXPORT = MDE 



MDL 



Global 

Global 

Global 

Global 

Global 



Const n_TABLE_nODIFY_STRUCTURE = MQM 

Const n_TABLE_DELETE = MD'l 

Const n_TABLE_RENAHE = MID 

Const n_TABLE_PACK = MD3 

Const n_TABLE_riAKEnAPPABLE = MIS 
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Global Const M_T ABLE_UNLI NK = Mlta 
Global Const M_T ABLE_REFRESH = M17 

Global Const H_TABLE_R ASTER_STYLE = MIM 
Global Const H_TABLE_R ASTER_REG = M13 
Global Const n_T00LS_R ASTER_REG = 1730 



r 

' Options menu 



G1 oba 1 
Global 
G1 obal 
G1 obal 
G1 obal 
G1 obal 
Global 
Global 
Global 
G1 obal 
Global 
Global 
Global 
Global 
Globa 1 
G loba 1 



Const n_FORnAT_PICK_LINE = 501 
Const n_FORriAT_PICK_FILL = 50E 
Const n_F0RnAT_PICK_SYnB0L = 503 
Const n_F0RMAT_PICK_F0NT = SOM 
Const n_WIND0U_BUTT0NPAD = t05 
Const n_WINDOy_LEGEND = tOt. 

Const njINDOU^STATISTICS = L07 
Const n_UINDOU_nAPBASIC = bOfl 
Const njINDOU_STATUSBAR = bit 
Const n_F0RnAT_CUST0n_C0L0RS = bl7 
Const n_EDIT_PREFERENCES = BOfl 
Const n_EDIT_PREFERENCES_SYSTEn = ElO 
Const n_EDIT_PREFERENCES_FILE = Ell 
Const n_EDIT_PREFERENCES_MAP = ElE 
Const n_EDIT_PREFERENCES_COUNTRY = E13 
Const n_EDIT_PREFERENCES_PATH = ElM 



' Window menu 



Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 



Const n_UIND0U_BR0WSE = bOl 
Const n_UIND0U_nAP = bOE 
Const n_UIND0U_GRAPH = b03 
Const n_UIND0U_LAY0UT = bOM 
Const n_UINDOU_REDISTRICT = bl5 
Const n_WINDOU_REDRAW = blO 
Const n_UIND0U_TILE = bll 
Const n_WINDOU_CASCADE = blE 
Const n_WIND0U_ARRANGEIC0NS = bl3 
Const n_UIND0U_n0RE = blM 
Const n_WIND0U_FIRST = bED 



' Note: the End through fiOth windows can be accessed as ( H_lilIND01il_FIRST + i -1 ) 



' Help menu 



Global Const 
Global Const 
Global Const 
Global Const 
Global Const 
Global Const 



H_HELP_CONTENTS = lEDE 
M_HELP_SEARCH = 1E03 
M_HELP_USE_HELP = lEDM 
f1_HELP_TECHSUPP0RT = lEOfl 
f1_HELP_C0NNECT_niF0RUn = lEO^ 
n_HELP_AB0UT = 1ED5 



Global Const n_HELP_CONTEXTSENSITIVE = lEOl 
Global Const n_HELP_HELPhODE = lEOb 



' Browse menu 



Global Const n_BROUSE_PICK_FIELDS = 70M 
Global Const n_BR0USE_0PTI0NS = 703 



' Nap menu 



Global Const n_HAP_L A YER_C0NTR0L = flOl 
Global Const n_nAP_THEMATIC = 307 
Global Const n_nAP_nODIFY_THEnATIC = 30fl 
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Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 



Const f1_nAP_CHANGE_VIEU = fiDS 
Const n_nAP_CLONE_nAPPER = fill 
Const n_nAP_PREVIOUS = fiOb 
Const n_nAP_ENTIRE_LAYER = fiD7 
Const n_nAP_CLEAR_CUSTOn_LABELS = filM 
Const n_nAP_SAVE_COSnETIC = fiDT 
Const n_nAP_CLEAR_COSnETIC = filD 
Const n_nAP_SET_CLIP_REGION = filB 
Const n_nAP_CLIP_REGION_ONOFF = fll3 
Const n_nAP_SETUPDIGITIZER = fi03 
Const n_nAP_0PTI0NS = fiOB 



' Layout menu 

r 



Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 



Const n_LAYOUT_CHANGE_VIEU = TOE 
Const n_LAYOUT_ACTUAL = TD3 
Const n_LAYOUT_ENTIRE = TDM 
Const n_LAYOUT_PREVIOUS = TD5 
Const n_LAYOUT_BRINGEFRONT = TDb 
Const n_LAYOUT_SENDEBACK = TD7 
Const n_LAYOUT_ALIGN = TDfi 
Const n_LAY0UT_DR0PSHAD0US = TDT 
Const n_LAYOUT_DISPLAYOPTIONS = TDl 



' Graph menu 



Global Const H_GRAPH_TYPE = IDDl 
Global Const H_GR APH_LABEL_AXIS = IDDE 
Global Const H_GR APH_VALUE_AXIS = 1DD3 
Global Const H^GR APH^SERIES = IDDM 



* riapBasic menu 

t 



Global Const n_n APBASIC_CLEAR = llDl 
Global Const n_HAPBASIC_SA VECONTENTS 



IIDE 



* Redistrict menu 



Global Const n_REDISTRICT_ASSIGN = 7DS 
Global Const n_REDISTRICT_TARGET = 7DL 
Global Const n_REDISTRICT_ADD = 7D7 
Global Const n_REDISTRICT_DELETE = 7Dfi 
Global Const n_REDISTRICT_OPTI ONS = 7DT 



' Main Buttonpad 



Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 



Const n_T00LS_SELECT0R = 17D1 
Const n_TOOLS_SEARCH_RECT = 17EE 
Const n_TOOLS_SEARCH_RADIUS = 17D3 
Const n_TOOLS_SEARCH_BOUNDARY = 17DM 
Const n_T00LS_EXPAND = 17D5 
Const n_T00LS_SHRINK = 17DL 
Const n_TOOLS_RECENTER = 17DB 
Const n_T00LS_PNT_(3UERY = 17D7 
Const n_T00LS_LABELER = 17Dfi 
Const n_T00LS_DRAGUIND0U = 173M 
Const n_T00LS_RULER = 1710 



' Drawing Buttonpad 



Global Const n_T00LS_P0INT = 1711 
Global Const n_T00LS_LINE = 171B 
Global Const n_T00LS_P0LYLINE = 1713 
Global Const n_T00LS_ARC = 171L 



254 



Global Const n_T00LS_P0LYG0N = 17m 
Global Const n_T00LS_ELLIPSE = 1715 
Global Const n_TOOLS_RECTANGLE = 1717 
Global Const n_T00LS_R0UNDEDRECT = 171fl 
Global Const H_T00LS_TEXT = 170T 
Global Const H_T00LS_FR AOE = 1711 
Global Const n_T00LS_ADI)_N0DE = 1723 



' rienu and ButtonPad items that do not appear in the standard menus 



Global Const H_TOOLS_nAPBASIC = 1720 
Global Const n_T00LS_SEARCH_P0LYG0N = 1733 



' end of I1ENU.DEF 
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Module 8. SPATIAL SELECTION PROGRAM 



Purpose: A MapBasic program that spatially selects the desired data within 50 miles of the 

specified location and locates the closest Army Reserve support facilities. 

Source Type; MapBasic Spatial Application Development Language 

Source File: ARIESARCH.MBA 

Code Listing: 



t 

» ARIES SDSS SPATIAL SELECTION PROGRAM -- PHASE One 

t 

» EXTRACTS SELECTED DATA FROM AROUND PROPOSED FACILITY SITE 

t 

Include "c: \mapinf o\mapbasic\mapbasic • def " 

Include ”c: \mapinf o\mapbasic\menu -def" 

Include ”c: \mapinf o\mapb as ic\ icons -def” 

Declare Sub Main 

Global AnSA_ID-.AnSA_Dist-, 

ECS.ID-. ECS_Dist. 

RZA_IDi RZA_Dist-, 

f ProposedFaci 1 i ty T f AreaD istance T fAreaFacIDi f AreaZ ipCode ■» 
f AreaGlfi -if ArealRR if AreafiMA iTargetZip-j cPropFacID As String 

Sub MAIN 

Dim FacIDLatn FacIDLong 

Dim ob jAreaBuf f er T ob jDis tanceBuf f er T objGlflBuffer 
Dim iRowNum 

Dim cFilePath-* AuthStrength 



cFilePath = App 1 i cationDirectory$ ( ) 

Set dap Center (-Tb-»37) Zoom 3500 Units "mi” 

Create Index On US_Zips ( Zip_Code ) 

Create Index on AMSA ( Fac_Zip ) 

Create Index on ECS(Fac_Zip) 

Create Index on RZA(Zip) 

Create Index on GEOREF ( Fac_ID ) 

Create Index on GlfiQIE(Zip) 

Create Index on IRR(Zipc) 

Create Index on fitlACZip) 

Create Index on Non_Clos ( Zip ) 

f AreaDistance = cFilePath 8 "AriesDataXAreaDist . DBF" 
fAreaFacID = cFilePath 8 "AriesDataXAreaFac . DBF" 
fAreaZipCode = cFilePath 8 "Ar iesDataXAreaZip . DBF" 
f ProposedFacil ity = cFilePath 8 "AriesDataXPropFac . DBF" 

fAreaGlfl = cFilePath 8 "Ar i esDataXAreaGlB . DBF" 
fArealRR = cFilePath 8 " Ar i esDataXArealRR . DBF" 
fAreafidA = cFilePath 8 " Ar i esData\Area(3dA . DBF" 

Open Table f AreaDistance 
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As Float 
As Object 
As Integer 

As String 



Delete From AreaDist 



Open Table fAreaFacID 
Delete From AreaFac 

Open Table f AreaZ ipCode 
Delete From AreaZip 

Open Table f ProposedFaci 1 i ty 
cPropFacID = Pr opFac • Fac_ID 
Pack Table PropFac Data 
Close Table PropFac 

Open Table fAreaGlfl 
Delete From AreaGlfi 

Open Table fArealRR 
Delete From ArealRR 

Open Table fArea(3HA 
Delete From AreaflllA 



(1) DETERIIINE LATITUDE & LONGITUDE OF TARGET ZIP CODE 
(E) CENTER MAP AT TARGET ZIP 

(3) CREATE SOni RADIUS CIRCLE AROUND TARGET ZIP CODE- 



Find Using GEOREF ( Fac^ID ) 

Find cPropFacID 

FacIDLat = Commandinf o ( CHD_INF0_X ) 

FacIDLong = CommandInf o ( CI1D_INFO_Y ) 

Set CoordSys Earth 

'Create Poi nt ( FacIDLat i FacIDLong) Symbol REDt SM) 

Insert Into Sites (obj) Values ( CreatePo in t ( FacIDLat t FacIDLong)) 
Update Sites Set Fac_ID = cPropFacID Where RowID = 1 

Set flap Center ( FacIDLat i FacIDLong ) Zoom 500 Units ”mi" 

Set Distance Units "mi” 

ob jAreaBuf f er = CreateCircle (FacIDLat iFacIDLongnSO) 
objGlflBuffer = Cr eateCir c 1 e ( FacIDLat n FacIDLong t 50 ) 
ob jDistanceBuf f er = Cr eateCircle ( FacIDLat n FacIDLong n 300 ) 



BUILD A TABLE OF ZIPCODES U/IN 50 fll OF THE PROPOSED 
FACILITY 



Select Zip_Code From US_Zips 

Where Obj Within ob jAreaBuf f er order by Zip_Code into TempZip 

Insert Into AreaZip 
Select * From TempZip 

Commit Table AreaZip 
Pack Table AreaZip Data 



BUILD A TABLE OF FACILITY ID'S W/IN 50 MI OF THE PROPOSED 
FACILITY 



Select Fac_ID From GEOREF 

Where Obj Within ob jAreaBuf fer order by Fac_ID into TempFacID 
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Insert Into AreaFac 

Select * From TempFacID 

Commit Table AreaFac 
Pack Table AreaFac Data 



DETERHINE DISTANCE TO NEAREST RECRUIT STATION 



Select * From RZA 

Uhere Obj Uithin objDistanceBuffer into TempRZA 

Select Distance(CentroidX(obj)TCentroidY(obj)TFacIDLatTFacIDLongT"mi") 
"Distance" 

From TempRZA order by Distance into TempRZA_Dist 
RZA_Dist = TempRZA_Dist . Distance 



DETERMINE DISTANCE TO NEAREST AMSA LOCATION 



Select t From AMSA 

Uhere Obj Uithin ob jDistanceBuf f er into TempAMSA 

Select Distance (CentroidX (obj) iCentroidY(obj) TFacIDLatTFacIDLongi"mi") 
"D i stance" 

From TempAMSA order by Distance into TempAMSA_D ist 
AMSA_Dist = TempAMS A_D i St • D i stance 



' DETERMINE DISTANCE TO NEAREST EQUIPMENT SITE 

Select * From ECS 

Uhere Obj Uithin ob jDi stanceBuf f er into TempECS 

Select Distance (CentroidX (obj) iCentroidY(obj) iFacIDLatTFacIDLongn"mi") 
"Distance" 

From TempECS order by Distance into TempECSJist 
ECS_Dist = TempECS_Dist . D is tance 



DETERMINE AUTHORIZED STRENGTH OF THE NAT GUARD UNITS 
UITHIN SO MILES OF TARGET ZIP CODE 



Select * From N0N_CL0S 

Uhere Obj Uithin ob j AreaBuf f er into TempNGUnits 

Select SUM(AUTH)"NO_AUTH_NG" 

From TempNGUnits into Strength 

AuthStrength = Strength . N0_AUTH_NG 



OUTPUT AMSA-, ECS-, RZA DISTANCES TO AREA DISTANCE FILE 



Insert into AreaDist 

Values (AMSA_Disti ECS_Disti RZA_Dist-, AuthStrength) 
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Commit Table AreaDist 
Pack Table AreaDist Data 



BUILD A TABLE OF Gift Personnel U/IN SO HI OF THE PROPOSED 
FACILITY 

Select UIC-. LEFT$ (ZIP-.S ) "ZIPCODE"-. PRI "HOS" From GlfiCUE 
Where Obj Within objGlfiBuffer and PRI <> "" 

Order by UICt ZIP into TempGlB 

Insert Into AreaGlB 
Select t From TempGlS 

Commit Table AreaGlfi 
Pack Table AreaGlfi Data 



BUILD A TABLE OF IRR Personnel W/IN SO HI OF THE PROPOSED 
FACILITY 



Select ZIPC "ZIP"-. LEFT$ ( PHOS 3 ) "I10S" From IRR 

Where Obj Within ob j AreaBuf f er and ZIPC <> "" and PflOS <> "" 

Order by Zipc into TempIRR 

Insert Into ArealRR 
Select * From TempIRR 

Commit Table ArealRR 
Pack Table ArealRR Data 



' BUILD A TABLE OF (2I1A Personnel W/IN SO HI OF THE PROPOSED 

' FACILITY 



Select LEFT$ (ZIPiS) "ZIPCODE"-. flWCATlB-. [1WCAT3A-. (1BCAT1E-. tlBCATBA-. 

HHCAT1E-. riHCAT3A From AHA 
Where Obj Within ob j AreaBuf fer 
Order by Zip into TempfiflA 

Insert Into AreatSdA 
Select * From Temp(2f1A 

Commit Table AreafiflA 
Pack Table Area(2riA Data 



f t****tt* tt************t ******************** *********** 

' END HAIN PROGRAM 

f *****% ^lit******* ********************************* ******************* 

Delete from Sites 
Commit Table Sites 
Pack Table Sites Data 

Exit Sub 

end SUB 
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